<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="UTF-8">
	<title>SonarQube Vulnerability Report</title>
	<style>
		/*
	The sss stylesheet is released under the MIT license.
	<https://github.com/Thiht/sss>
	*/
		pre,
		td,
		th {
			padding: 5px 10px
		}

		code,
		hr,
		pre,
		thead {
			background: #EEE
		}

		body {
			color: #333;
			font-family: 'Segoe UI', 'Lucida Grande', Helvetica, sans-serif;
			line-height: 1.5;
		}

		div.summup {
			max-width: 800px;
			margin: 50px auto;
		}
		div.detail {
			padding: 20px;
		}

		h1,
		h2,
		h3,
		h4,
		h5,
		h6 {
			font-weight: 400;
			line-height: 1em;
			margin: 20px 0
		}

		h1 {
			font-size: 2.25em
		}

		h2 {
			font-size: 1.75em
		}

		h3 {
			font-size: 1.5em
		}

		h4,
		h5,
		h6 {
			font-size: 1.25em
		}

		a {
			color: #08C;
			text-decoration: none
		}

		a:focus,
		a:hover {
			text-decoration: underline
		}

		a:visited {
			color: #058
		}

		img {
			max-width: 100%
		}

		li+li {
			margin-top: 3px
		}

		dt {
			font-weight: 700
		}

		code {
			font-family: Consolas, "Lucida Console", monospace;
			padding: 1px 5px
		}

		pre {
			white-space: pre-wrap
		}

		pre code {
			padding: 0
		}

		blockquote {
			border-left: 5px solid #EEE;
			margin: 0;
			padding: 0 10px
		}

		table {
			border-collapse: collapse;
			width: 100%
		}

		table+table {
			margin-top: 1em
		}

		thead {
			text-align: left
		}

		td,
		th {
			border: 1px solid #EEE
		}
		td.component{
			word-break: break-all;
		}

		hr {
			border: 0;
			height: 1px
		}
	</style>
	<style>
		.banner {
			text-align: center;
		}

		canvas {
			display: block;
			margin: 10px auto;
		}
	</style>
</head>

<body>
	<div class=summup>
		<!-- insert your company banner here -->
		<!--
		<p class="banner">
			<a href="https://www.soprasteria.com/" target="_blank">
				<img src="https://upload.wikimedia.org/wikipedia/en/thumb/0/02/Sopra_Steria_logo.svg/1280px-Sopra_Steria_logo.svg.png" alt="Sopra Steria" height="50">
			</a>
		</p>
		-->

		<h1>SonarQube Vulnerability Report</h1>

		<dl>
			<dt>Report Generated On</dt>
			<dd>Sat Aug 31 2019</dd>

			<dt>Project Name</dt>
			<dd>webgoat</dd>

			<dt>Application</dt>
			<dd>webgoat</dd>

			<dt>Release</dt>
			<dd>8.0.0</dd>

			<dt>Delta analysis</dt>
			<dd>No</dd>

			
		</dl>

		<h2>Summary of the Detected Vulnerabilities</h2>
		<table>
			<thead>
				<tr>
					<th></th>
					<th>Severity</th>
					<th>Number of Issues</th>
				</tr>
			</thead>
			<tbody>
				<tr>
					<td style="background-color:#2c3e50"></td>
					<td>BLOCKER</td>
					<td>4</td>
				</tr>
				<tr>
					<td style="background-color: #d43223"></td>
					<td>CRITICAL</td>
					<td>0</td>
				</tr>
				<tr>
					<td style="background-color: #f39c12"></td>
					<td>MAJOR</td>
					<td>0</td>
				</tr>
				<tr>
					<td style="background-color: #319ddb"></td>
					<td>MINOR</td>
					<td>0</td>
				</tr>
			</tbody>
		</table>

		
		<canvas id="vulnerabilitiesPieChart" width="200" height="200"></canvas>
		
	</div>

	<div class=detail>
		
		<h2>Detail of the Detected Vulnerabilities</h2>
		<table>
			<thead>
				<tr>
					<th>Rule</th>
					<th>Severity</th>
					<th>Component</th>
					<th>Line</th>
					<th>Description</th>
					<th>Message</th>
					<th style="display:none;">Key</th>
				</tr>
			</thead>
			<tbody>
				<tr>
					<td><a href="http://host:port/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">xxe/src/main/java/org/owasp/webgoat/plugin/User.java</td>
					<td>38</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;password&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWygKeaIU0pRxZ-RNGbO</td>
				</tr>
				
				<tr>
					<td><a href="http://host:port/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java</td>
					<td>12</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PASSWORD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWygKeRaU0pRxZ-RNGT5</td>
				</tr>
				
				<tr>
					<td><a href="http://host:port/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java</td>
					<td>13</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PASSWORD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWygKeRaU0pRxZ-RNGT6</td>
				</tr>
				
				<tr>
					<td><a href="http://host:port/coding_rules#rule_key=squid:S2068">squid:S2068</a></td>
					<td>BLOCKER</td>
					<td class="component">challenge/src/main/java/org/owasp/webgoat/plugin/SolutionConstants.java</td>
					<td>14</td>
					<td>Credentials should not be hard-coded</td>
					<td>&#39;PASSWORD&#39; detected in this expression, review this potentially hardcoded credential.</td>
					<td style="display:none;">AWygKeRcU0pRxZ-RNGT7</td>
				</tr>
				
			</tbody>
		</table>

		

		<h3>Known Security Rules</h3>
		<table style="table-layout: fixed; word-wrap: break-word">
			<thead>
				<tr>
					<th>Rule</th>
					<th>Description</th>
				</tr>
			</thead>
			<tbody>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3318">squid:S3318</a>
					</td>
					<td>
						<details>
							<p>Data in a web session is considered inside the "trust boundary". That is, it is assumed to be trustworthy. But storing unvetted data from an
unauthenticated user violates the trust boundary, and may lead to that data being used inappropriately.</p>
<p>This rule raises an issue when data from <code>Cookie</code>s or <code>HttpServletRequest</code>s is stored in a session. </p>
<h2>Noncompliant Code Example</h2>
<pre>
login = request.getParameter("login");
session.setAttribute("login", login);  // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/501">MITRE, CWE-501</a> - Trust Boundary Violation </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1148">squid:S1148</a>
					</td>
					<td>
						<details>
							<p><code>Throwable.printStackTrace(...)</code> prints a <code>Throwable</code> and its stack trace to some stream. By default that stream
<code>System.Err</code>, which could inadvertently expose sensitive information.</p>
<p>Loggers should be used instead to print <code>Throwable</code>s, as they have many advantages:</p>
<ul>
  <li> Users are able to easily retrieve the logs. </li>
  <li> The format of log messages is uniform and allow users to browse the logs easily. </li>
</ul>
<p>This rule raises an issue when <code>printStackTrace</code> is used without arguments, i.e. when the stack trace is printed to the default
stream.</p>
<h2>Noncompliant Code Example</h2>
<pre>
try {
  /* ... */
} catch(Exception e) {
  e.printStackTrace();        // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
try {
  /* ... */
} catch(Exception e) {
  LOGGER.log("context", e);
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2386">squid:S2386</a>
					</td>
					<td>
						<details>
							<p>There is no good reason to have a mutable object as the <code>public</code> (by default), <code>static</code> member of an <code>interface</code>.
Such variables should be moved into classes and their visibility lowered. </p>
<p>Similarly, mutable <code>static</code> members of classes and enumerations which are accessed directly, rather than through getters and setters,
should be protected to the degree possible. That can be done by reducing visibility or making the field <code>final</code> if appropriate. </p>
<p>Note that making a mutable field, such as an array, <code>final</code> will keep the variable from being reassigned, but doing so has no effect on
the mutability of the internal state of the array (i.e. it doesn't accomplish the goal).</p>
<p>This rule raises issues for <code>public static</code> array, <code>Collection</code>, <code>Date</code>, and <code>awt.Point</code> members.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public interface MyInterface {
  public static String [] strings; // Noncompliant
}

public class A {
  public static String [] strings1 = {"first","second"};  // Noncompliant
  public static String [] strings2 = {"first","second"};  // Noncompliant
  public static List&lt;String&gt; strings3 = new ArrayList&lt;&gt;();  // Noncompliant
  // ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/582.html">MITRE, CWE-582</a> - Array Declared Public, Final, and Static </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/607.html">MITRE, CWE-607</a> - Public Static Final Field References Mutable Object </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/rwBc">CERT, OBJ01-J.</a> - Limit accessibility of fields </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/JQLEAw">CERT, OBJ13-J.</a> - Ensure that references to mutable objects are not exposed
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3355">squid:S3355</a>
					</td>
					<td>
						<details>
							<p>Every filter defined in <code>web.xml</code> file should be used in a <code>&lt;filter-mapping&gt;</code> element. Otherwise such filters are not
invoked.</p>
<h2>Noncompliant Code Example</h2>
<pre>
  &lt;filter&gt;
     &lt;filter-name&gt;DefinedNotUsed&lt;/filter-name&gt;
     &lt;filter-class&gt;com.myco.servlet.ValidationFilter&lt;/filter-class&gt;
  &lt;/filter&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
  &lt;filter&gt;
     &lt;filter-name&gt;ValidationFilter&lt;/filter-name&gt;
     &lt;filter-class&gt;com.myco.servlet.ValidationFilter&lt;/filter-class&gt;
  &lt;/filter&gt;

  &lt;filter-mapping&gt;
     &lt;filter-name&gt;ValidationFilter&lt;/filter-name&gt;
     &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
  &lt;/filter-mapping&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top Ten 2013 Category A1</a> - Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2384">squid:S2384</a>
					</td>
					<td>
						<details>
							<p>Mutable objects are those whose state can be changed. For instance, an array is mutable, but a String is not. Mutable class members should never be
returned to a caller or accepted and stored directly. Doing so leaves you vulnerable to unexpected changes in your class state.</p>
<p>Instead use an unmodifiable <code>Collection</code> (via <code>Collections.unmodifiableCollection</code>,
<code>Collections.unmodifiableList</code>, ...) or make a copy of the mutable object, and store or return the copy instead.</p>
<p>This rule checks that arrays, collections and Dates are not stored or returned directly.</p>
<h2>Noncompliant Code Example</h2>
<pre>
class A {
  private String [] strings;

  public A () {
    strings = new String[]{"first", "second"};
  }

  public String [] getStrings() {
    return strings; // Noncompliant
  }

  public void setStrings(String [] strings) {
    this.strings = strings;  // Noncompliant
  }
}

public class B {

  private A a = new A();  // At this point a.strings = {"first", "second"};

  public void wreakHavoc() {
    a.getStrings()[0] = "yellow";  // a.strings = {"yellow", "second"};
  }
}
</pre>
<h2>Compliant Solution</h2>
<pre>
class A {
  private String [] strings;

  public A () {
    strings = new String[]{"first", "second"};
  }

  public String [] getStrings() {
    return strings.clone();
  }

  public void setStrings(String [] strings) {
    this.strings = strings.clone();
  }
}

public class B {

  private A a = new A();  // At this point a.strings = {"first", "second"};

  public void wreakHavoc() {
    a.getStrings()[0] = "yellow";  // a.strings = {"first", "second"};
  }
}

</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/374">MITRE, CWE-374</a> - Passing Mutable Objects to an Untrusted Method </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/375">MITRE, CWE-375</a> - Returning a Mutable Object to an Untrusted Caller </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/zQCuAQ">CERT, OBJ05-J.</a> - Do not return references to private mutable class members
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QIEVAQ">CERT, OBJ06-J.</a> - Defensively copy mutable inputs and mutable internal
  components </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/JQLEAw">CERT, OBJ13-J.</a> - Ensure that references to mutable objects are not exposed
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/kwCuAQ">CERT, OOP08-CPP.</a> - Do not return references to private data </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3369">squid:S3369</a>
					</td>
					<td>
						<details>
							<p>Websphere, Tomcat, and JBoss web servers allow the definition of role-based access to servlets. It may not be granular enough for your purposes,
but it's a start, and should be used at least as a base.</p>
<p>This rule raises an issue when a <em>web.xml</em> file has no <code>&lt;security-constraint&gt;</code> elements.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/284.html">MITRE, CWE-284</a> - Improper Access Control </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control">OWASP Top Ten 2013 Category A7</a> - Missing
  Function Level Access Control </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2039">squid:S2039</a>
					</td>
					<td>
						<details>
							<p>Failing to explicitly declare the visibility of a member variable could result it in having a visibility you don't expect, and potentially leave it
open to unexpected modification by other classes. </p>
<h2>Noncompliant Code Example</h2>
<pre>
class Ball {
    String color="red";  // Noncompliant
}
enum A {
  B;
  int a;
}
</pre>
<h2>Compliant Solution</h2>
<pre>
class Ball {
    private String color="red";  // Compliant
}
enum A {
  B;
  private int a;
}
</pre>
<h2>Exceptions</h2>
<p>Members annotated with Guava's <code>@VisibleForTesting</code> annotation are ignored, as it indicates that visibility has been purposely relaxed
to make the code testable.</p>
<pre>
class Cone {
  @VisibleForTesting
  Logger logger; // Compliant
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2278">squid:S2278</a>
					</td>
					<td>
						<details>
							<p>According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:</p>
<blockquote>
  <p>Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer
  provides the security that is needed to protect federal government information.</p>
  <p>Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.</p>
</blockquote>
<p>For similar reasons, RC2 should also be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
</pre>
<h2>Compliant Solution</h2>
<pre>
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VwAZAg">CERT, MSC61-J.</a> - Do not use insecure or weak cryptographic algorithms </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#DES_USAGE">DES / DESede Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2277">squid:S2277</a>
					</td>
					<td>
						<details>
							<p>Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an
issue as soon as a literal value starts with <code>RSA/NONE</code>. </p>
<h2>Noncompliant Code Example</h2>
<pre>
Cipher rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");
</pre>
<h2>Compliant Solution</h2>
<pre>
Cipher rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/780.html">MITRE CWE-780</a> - Use of RSA Algorithm without OAEP </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">MITRE CWE-327</a>: Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration">OWASP Top Ten 2013 Category A5</a> - Security
  Misconfiguration </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#RSA_NO_PADDING">RSA NoPadding Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2245">squid:S2245</a>
					</td>
					<td>
						<details>
							<p>When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that
will be generated, and use this guess to impersonate another user or access sensitive information.</p>
<p>As the <code>java.util.Random</code> class relies on a pseudorandom number generator, this class and relating <code>java.lang.Math.random()</code>
method should not be used for security-critical applications or for protecting sensitive data. In such context, the
<code>java.security.SecureRandom</code> class which relies on a cryptographically strong random number generator (RNG) should be used in place.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Random random = new Random();
byte bytes[] = new byte[20];
random.nextBytes(bytes);
</pre>
<h2>Compliant Solution</h2>
<pre>
SecureRandom random = new SecureRandom();
byte bytes[] = new byte[20];
random.nextBytes(bytes);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/338.html">MITRE, CWE-338</a> - Use of Cryptographically Weak Pseudo-Random Number Generator
  (PRNG) </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/330.html">MITRE, CWE-330</a> - Use of Insufficiently Random Values </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/326.html">MITRE, CWE-326</a> - Inadequate Encryption Strength </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/310">MITRE, CWE-310</a> - Cryptographic Issues </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/mAFqAQ">CERT, MSC02-J.</a> - Generate strong random numbers </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qw4">CERT, MSC30-C.</a> - Do not use the rand() function for generating pseudorandom
  numbers </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/WYIyAQ">CERT, MSC50-CPP.</a> - Do not use std::rand() for generating pseudorandom
  numbers </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#PREDICTABLE_RANDOM">Predictable Pseudo Random Number
  Generator</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2258">squid:S2258</a>
					</td>
					<td>
						<details>
							<p>By contract, the <code>NullCipher</code> class provides an "identity cipher" <del></del> one that does not transform or encrypt the plaintext in
any way. As a consequence, the ciphertext is identical to the plaintext. So this class should be used for testing, and never in production code.</p>
<h2>Noncompliant Code Example</h2>
<pre>
NullCipher nc=new NullCipher();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327</a>: Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#NULL_CIPHER">NullCipher Unsafe</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2257">squid:S2257</a>
					</td>
					<td>
						<details>
							<p>The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has
been protected. Standard algorithms like <code>SHA-256</code>, <code>SHA-384</code>, <code>SHA-512</code>, ... should be used instead.</p>
<p>This rule tracks creation of <code>java.security.MessageDigest</code> subclasses.</p>
<h2>Noncompliant Code Example</h2>
<pre>
MyCryptographicAlgorithm extends MessageDigest {
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#CUSTOM_MESSAGE_DIGEST">MessageDigest is Custom</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2254">squid:S2254</a>
					</td>
					<td>
						<details>
							<p>According to the Oracle Java API, the <code>HttpServletRequest.getRequestedSessionId()</code> method:</p>
<blockquote>
  <p>Returns the session ID specified by the client. This may not be the same as the ID of the current valid session for this request. If the client
  did not specify a session ID, this method returns null.</p>
</blockquote>
<p>The session ID it returns is either transmitted in a cookie or a URL parameter so by definition, nothing prevents the end-user from manually
updating the value of this session ID in the HTTP request. </p>
<p>Here is an example of a updated HTTP header:</p>
<pre>
GET /pageSomeWhere HTTP/1.1
Host: webSite.com
User-Agent: Mozilla/5.0
Cookie: JSESSIONID=Hacked_Session_Value'''"&gt;
</pre>
<p>Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (E.G.
Tomcat or Jetty) to see if the value matches the ID of an an existing session. If it does not, the user should be considered unauthenticated.
Moreover, this session ID should never be logged to prevent hijacking of active sessions.</p>
<h2>Noncompliant Code Example</h2>
<pre>
if(isActiveSession(request.getRequestedSessionId()) ){
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/807">MITRE, CWE-807</a> - Reliance on Untrusted Inputs in a Security Decision </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">OWASP Top Ten 2013 Category A2</a> -
  Broken Authentication and Session Management </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#SERVLET_SESSION_ID">Untrusted Session Cookie Value</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2976">squid:S2976</a>
					</td>
					<td>
						<details>
							<p>Using <code>File.createTempFile</code> as the first step in creating a temporary directory causes a race condition and is inherently unreliable and
insecure. Instead, <code>Files.createTempDirectory</code> (Java 7+) or a library function such as Guava's similarly-named
<code>Files.createTempDir</code> should be used.</p>
<p>This rule raises an issue when the following steps are taken in immediate sequence:</p>
<ul>
  <li> call to <code>File.createTempFile</code> </li>
  <li> delete resulting file </li>
  <li> call <code>mkdir</code> on the File object </li>
</ul>
<p><strong>Note</strong> that this rule is automatically disabled when the project's <code>sonar.java.source</code> is lower than <code>7</code>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
File tempDir;
tempDir = File.createTempFile("", ".");
tempDir.delete();
tempDir.mkdir();  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
Path tempPath = Files.createTempDirectory("");
File tempDir = tempPath.toFile();
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities">OWAPS Top Ten 2013 Category A9</a> - Using
  Components with Known Vulnerabilities </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3751">squid:S3751</a>
					</td>
					<td>
						<details>
							<p>A <code>@Controller</code> method with a <code>@RequestMapping</code> annotation will be called to handle matching web requests. That will happen
even if the method is <code>private</code>, because Spring invokes such methods via reflection, without checking visibility. </p>
<p>So marking a sensitive method <code>private</code> may seem like a good way to control how such code is called. Unfortunately, not all Spring
frameworks ignore visibility in this way. For instance, if you've tried to control web access to your sensitive, <code>private</code>,
<code>@RequestMapping</code> method by marking it <code>@Secured</code> ... it will still be called, whether or not the user is authorized to access
it. That's because AOP proxies are not applied to non-public methods. </p>
<h2>Noncompliant Code Example</h2>
<pre>
@RequestMapping("/greet", method = GET)
private String greet(String greetee) {  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
@RequestMapping("/greet", method = GET)
public String greet(String greetee) {
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1313">squid:S1313</a>
					</td>
					<td>
						<details>
							<p>Hardcoding an IP address into source code is a bad idea for several reasons:</p>
<ul>
  <li> a recompile is required if the address changes </li>
  <li> it forces the same address to be used in every environment (dev, sys, qa, prod) </li>
  <li> it places the responsibility of setting the value to use in production on the shoulders of the developer </li>
  <li> it allows attackers to decompile the code and thereby discover a potentially sensitive address </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
String ip = "127.0.0.1";
Socket socket = new Socket(ip, 6667);
</pre>
<h2>Compliant Solution</h2>
<pre>
String ip = System.getProperty("myapplication.ip");
Socket socket = new Socket(ip, 6667);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1444">squid:S1444</a>
					</td>
					<td>
						<details>
							<p>There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a
state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to
<code>null</code>. </p>
<h2>Noncompliant Code Example</h2>
<pre>
public class Greeter {
  public static Foo foo = new Foo();
  ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class Greeter {
  public static final Foo FOO = new Foo();
  ...
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/500.html">MITRE, CWE-500</a> - Public Static Field Not Marked Final </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/QQBqAQ">CERT OBJ10-J.</a> - Do not use public static nonfinal fields </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2653">squid:S2653</a>
					</td>
					<td>
						<details>
							<p>There is no reason to have a <code>main</code> method in a web application. It may have been useful for debugging during application development,
but such a method should never make it into production. Having a <code>main</code> method in a web application opens a door to the application logic
that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be
present.</p>
<p>This rule raises an issue when a <code>main</code> method is found in a servlet or an EJB.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyServlet extends HttpServlet {
  public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
    if (userIsAuthorized(req)) {
      updatePrices(req);
    }
  }

  public static void main(String[] args) { // Noncompliant
    updatePrices(req);
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/VoB8Bw">CERT, ENV06-J.</a> - Production code must not contain debugging entry points
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3749">squid:S3749</a>
					</td>
					<td>
						<details>
							<p>Spring <code>@Controller</code>s, <code>@Service</code>s, and <code>@Repository</code>s are singletons by default, meaning only one instance of the
class is ever instantiated in the application. Typically such a class might have a few <code>static</code> members, such as a logger, but all
non-<code>static</code> members should be managed by Spring. That is, they should have one of these annotations: <code>@Resource</code>,
<code>@Inject</code>, <code>@Autowired</code> or <code>@Value</code>.</p>
<p>Having non-injected members in one of these classes could indicate an attempt to manage state. Because they are singletons, such an attempt is
almost guaranteed to eventually expose data from User1's session to User2. </p>
<p>This rule raises an issue when a singleton <code>@Controller</code>, <code>@Service</code>, or <code>@Repository</code> has non-<code>static</code>
members that are not annotated with one of:</p>
<ul>
  <li> <code>org.springframework.beans.factory.annotation.Autowired</code> </li>
  <li> <code>org.springframework.beans.factory.annotation.Value</code> </li>
  <li> <code>javax.annotation.Inject</code> </li>
  <li> <code>javax.annotation.Resource</code> </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
@Controller
public class HelloWorld {

  private String name = null;

  @RequestMapping("/greet", method = GET)
  public String greet(String greetee) {

    if (greetee != null) {
      this.name = greetee;
    }

    return "Hello " + this.name;  // if greetee is null, you see the previous user's data
  }
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2658">squid:S2658</a>
					</td>
					<td>
						<details>
							<p>Dynamically loaded classes could contain malicious code executed by a static class initializer. I.E. you wouldn't even have to instantiate or
explicitly invoke methods on such classes to be vulnerable to an attack.</p>
<p>This rule raises an issue for each use of dynamic class loading.</p>
<h2>Noncompliant Code Example</h2>
<pre>
String className = System.getProperty("messageClassName");
Class clazz = Class.forName(className);  // Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top 10 2013 Category A1</a> - Injection </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S1989">squid:S1989</a>
					</td>
					<td>
						<details>
							<p>Even though the signatures for methods in a servlet include <code>throws IOException, ServletException</code>, it's a bad idea to let such
exceptions be thrown. Failure to catch exceptions in a servlet could leave a system in a vulnerable state, possibly resulting in denial-of-service
attacks, or the exposure of sensitive information because when a servlet throws an exception, the servlet container typically sends debugging
information back to the user. And that information could be very valuable to an attacker. </p>
<p>This rule checks all exceptions in methods named "do*" are explicitly handled in servlet classes.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws IOException, ServletException {
  String ip = request.getRemoteAddr();
  InetAddress addr = InetAddress.getByName(ip); // Noncompliant; getByName(String) throws UnknownHostException
  //...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public void doGet(HttpServletRequest request, HttpServletResponse response)
  throws IOException, ServletException {
  try {
    String ip = request.getRemoteAddr();
    InetAddress addr = InetAddress.getByName(ip);
    //...
  }
  catch (UnknownHostException uhex) {
    //...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/600.html">MITRE, CWE-600</a> - Uncaught Exception in Servlet </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/s4EVAQ">CERT, ERR01-J.</a> - Do not allow exceptions to expose sensitive information
  </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten Category A6</a> - Sensitive Data Exposure </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2068">squid:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Connection conn = null;
try {
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=steve&amp;password=blue"); // Noncompliant
  String uname = "steve";
  String password = "blue";
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=" + uname + "&amp;password=" + password); // Noncompliant

  java.net.PasswordAuthentication pa = new java.net.PasswordAuthentication("userName", "1234".toCharArray());  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
Connection conn = null;
try {
  String uname = getEncryptedUser();
  String password = getEncryptedPass();
  conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
        "user=" + uname + "&amp;password=" + password);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">OWASP Top Ten 2013 Category A2</a> -
  Broken Authentication and Session Management </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2078">squid:S2078</a>
					</td>
					<td>
						<details>
							<p>Applications that execute LDAP queries should neutralize any externally-provided values in those commands. Failure to do so could allow an attacker
to include input that changes the query so that unintended commands are executed, or sensitive data is exposed. Unhappily LDAP doesn't provide any
prepared statement interfaces like SQL to easily remove this risk. So each time a LDAP query is built dynamically this rule logs an issue.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public User lookupUser(String username, String base, String [] requestedAttrs) {

  // ...
  DirContext dctx = new InitialDirContext(env);

  SearchControls sc = new SearchControls();
  sc.setReturningAttributes(requestedAttrs);  // Noncompliant
  sc.setSearchScope(SearchControls.SUBTREE_SCOPE);

  String filter = "(&amp;(objectClass=user)(sAMAccountName=" + username + "))";

  NamingEnumeration results = dctx.search(base,  // Noncompliant
        filter,  // Noncompliant; parameter concatenated directly into string
        sc);
</pre>
<h2>Compliant Solution</h2>
<pre>
public User lookupUser(String username, String base, String [] requestedAttrs) {

  // ...
  DirContext dctx = new InitialDirContext(env);

  SearchControls sc = new SearchControls();
  sc.setReturningAttributes(buildAttrFilter(requestedAttrs));  // Compliant; method presumably scrubs input
  sc.setSearchScope(SearchControls.SUBTREE_SCOPE);

  String useBase = "ou=People";
  if (! base.startsWith(useBase)) {
    useBase = base;
  }

  String filter = "(&amp;(objectClass=user)(sAMAccountName=" + username.replaceAll("[()| ]","") + "))";

  NamingEnumeration results = dctx.search(useBase,  // Compliant; originally value used conditionally
        filter,  // Compliant; parameter NOT concatenated directly into string
        sc);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/90">MITRE CWE-90</a> - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP
  Injection') </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top Ten 2013 Category A1</a> - Injection </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/CgLEAw">CERT, IDS54-J.</a> - Prevent LDAP injection </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#LDAP_INJECTION">Potential LDAP Injection</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2076">squid:S2076</a>
					</td>
					<td>
						<details>
							<p>Applications that execute operating system commands or execute commands that interact with the underlying system should neutralize any
externally-provided values used in those commands. Failure to do so could allow an attacker to include input that executes unintended commands, or
exposes sensitive data.</p>
<p>This rule logs issues for dynamically-built commands, and when parameter values are used to influence how a command is run. it's then up to the
auditor to figure out if the command execution is secure or not. </p>
<h2>Noncompliant Code Example</h2>
<pre>
public void listContent(String input) {
  Runtime rt = Runtime.getRuntime();
  rt.exec("ls " + input); // Noncompliant; input could easily contain extra commands
  ...
}

public void execute(String command, String argument) {
  ProcessBuilder pb = new ProcessBuilder(command, argument); // Noncompliant
  ...
}

public void doTheThing(String path) {
  ProcessBuilder pb = new ProcessBuilder("ls");  // command hard coded. So far, so good
  pb.redirectOutput(path);  // Noncompliant
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/78">MITRE, CWE-78</a> - Improper Neutralization of Special Elements used in an OS Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/88">MITRE, CWE-88</a> - Argument Injection or Modification </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top Ten 2013 Category A1</a> - Injection </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> Derived from the FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#COMMAND_INJECTION">Potential Command Injection</a>
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2077">squid:S2077</a>
					</td>
					<td>
						<details>
							<p>Applications that execute SQL commands should neutralize any externally-provided values used in those commands. Failure to do so could allow an
attacker to include input that changes the query so that unintended commands are executed, or sensitive data is exposed.</p>
<p>This rule checks a variety of methods from different frameworks which are susceptible to SQL injection if not used properly. Frameworks which are
covered are Java JDBC, JPA, JDO, Hibernate and Spring. The following specific method signatures are tested. </p>
<ul>
  <li> <code>org.hibernate.Session.createQuery</code> </li>
  <li> <code>org.hibernate.Session.createSQLQuery</code> </li>
  <li> <code>java.sql.Statement.executeQuery</code> </li>
  <li> <code>java.sql.Statement.execute</code> </li>
  <li> <code>java.sql.Statement.executeUpdate</code> </li>
  <li> <code>java.sql.Statement.executeLargeUpdate</code> </li>
  <li> <code>java.sql.Statement.addBatch</code> </li>
  <li> <code>java.sql.Connection.prepareStatement</code> </li>
  <li> <code>java.sql.Connection.prepareCall</code> </li>
  <li> <code>java.sql.Connection.nativeSQL</code> </li>
  <li> <code>javax.persistence.EntityManager.createNativeQuery</code> </li>
  <li> <code>javax.persistence.EntityManager.createQuery</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.batchUpdate</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.execute</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.query</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForList</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForMap</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForObject</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForRowSet</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForInt</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.queryForLong</code> </li>
  <li> <code>org.springframework.jdbc.core.JdbcOperations.update</code> </li>
  <li> <code>org.springframework.jdbc.core.PreparedStatementCreatorFactory.&lt;init&gt;</code> </li>
  <li> <code>org.springframework.jdbc.core.PreparedStatementCreatorFactory.newPreparedStatementCreator</code> </li>
  <li> <code>javax.jdo.PersistenceManager.newQuery</code> </li>
  <li> <code>javax.jdo.Query.setFilter</code> </li>
  <li> <code>javax.jdo.Query.setGrouping</code> </li>
</ul>
<p>If a method is defined in an interface, implementations are also tested. For example this is the case for
<code>org.springframework.jdbc.core.JdbcOperations</code> , which is usually used as <code>org.springframework.jdbc.core.JdbcTemplate</code>). </p>
<h2>Noncompliant Code Example</h2>
<pre>
public User getUser(Connection con, String user) throws SQLException {

  Statement stmt1 = null;
  Statement stmt2 = null;
  PreparedStatement pstmt;
  try {
    stmt1 = con.createStatement();
    ResultSet rs1 = stmt1.executeQuery("GETDATE()"); // Compliant; parameters not used here

    stmt2 = con.createStatement();
    ResultSet rs2 = stmt2.executeQuery("select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=" + user);  // Noncompliant; parameter concatenated directly into query

    pstmt = con.prepareStatement("select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=" + user);  // Noncompliant; parameter concatenated directly into query
    ResultSet rs3 = pstmt.executeQuery();

    //...
}

public User getUserHibernate(org.hibernate.Session session, String userInput) {

  org.hibernate.Query query = session.createQuery(  // Compliant
            "FROM students where fname = " + userInput);  // Noncompliant; parameter binding should be used instead
  // ...
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public User getUser(Connection con, String user) throws SQLException {

  Statement stmt1 = null;
  PreparedStatement pstmt = null;
  String query = "select FNAME, LNAME, SSN " +
                 "from USERS where UNAME=?"
  try {
    stmt1 = con.createStatement();
    ResultSet rs1 = stmt1.executeQuery("GETDATE()");

    pstmt = con.prepareStatement(query);
    pstmt.setString(1, user);  // Compliant; PreparedStatements escape their inputs.
    ResultSet rs2 = pstmt.executeQuery();

    //...
  }
}

public User getUserHibernate(org.hibernate.Session session, String userInput) {

  org.hibernate.Query query =  session.createQuery("FROM students where fname = ?");
  query = query.setParameter(0,userInput);  // Parameter binding escapes all input
  // ...
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/564.html">MITRE, CWE-564</a> - SQL Injection: Hibernate </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/20.html">MITRE, CWE-20</a> - Improper Input Validation </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/943.html">MITRE, CWE-943</a> - Improper Neutralization of Special Elements in Data Query Logic
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/PgIRAg">CERT, IDS00-J.</a> - Prevent SQL injection </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top Ten 2013 Category A1</a> - Injection </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Insecure Interaction Between Components </li>
  <li> Derived from FindSecBugs rules <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JPA">Potential SQL/JPQL Injection
  (JPA)</a>, <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JDO">Potential SQL/JDOQL Injection (JDO)</a>, <a
  href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_HIBERNATE">Potential SQL/HQL Injection (Hibernate)</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2070">squid:S2070</a>
					</td>
					<td>
						<details>
							<p>The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is,
it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash
value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2,
MD4, MD6, RIPEMD160.</p>
<p>The following APIs are tracked for use of obsolete crypto algorithms:</p>
<p> * <code>java.security.AlgorithmParameters</code> (JDK)</p>
<p> * <code>java.security.AlgorithmParameterGenerator</code> (JDK)</p>
<p> * <code>java.security.MessageDigest</code> (JDK)</p>
<p> * <code>java.security.KeyFactory</code> (JDK)</p>
<p> * <code>java.security.KeyPairGenerator</code> (JDK)</p>
<p> * <code>java.security.Signature</code> (JDK)</p>
<p> * <code>javax.crypto.Mac</code> (JDK)</p>
<p> * <code>javax.crypto.KeyGenerator</code> (JDK)</p>
<p> * <code>org.apache.commons.codec.digest.DigestUtils</code> (Apache Commons Codec)</p>
<p> * <code>com.google.common.hash.Hashing</code> (Guava)</p>
<h2>Noncompliant Code Example</h2>
<pre>
MessageDigest md = MessageDigest.getInstance("SHA1");  // Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
MessageDigest md = MessageDigest.getInstance("SHA-256");
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/328">MITRE, CWE-328</a> - Reversible One-Way Hash </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/327">MITRE, CWE-327</a> - Use of a Broken or Risky Cryptographic Algorithm </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#WEAK_MESSAGE_DIGEST">MessageDigest Is Weak</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3281">squid:S3281</a>
					</td>
					<td>
						<details>
							<p>Default interceptors, such as application security interceptors, must be listed in the <code>ejb-jar.xml</code> file, or they will not be treated
as default. </p>
<p>This rule applies to projects that contain JEE Beans (any one of <code>javax.ejb.Singleton</code>, <code>MessageDriven</code>,
<code>Stateless</code> or <code>Stateful</code>).</p>
<h2>Noncompliant Code Example</h2>
<pre>
// file: ejb-interceptors.xml
&lt;assembly-descriptor&gt;
 &lt;interceptor-binding&gt;
      &lt;ejb-name&gt;*&lt;/ejb-name&gt;
      &lt;interceptor-class&gt;com.myco.ImportantInterceptor&lt;/interceptor-class&gt;&lt;!-- Noncompliant; will not be treated as default --&gt;
   &lt;/interceptor-binding&gt;
&lt;/assembly-descriptor&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
// file: ejb-jar.xml
&lt;assembly-descriptor&gt;
 &lt;interceptor-binding&gt;
      &lt;ejb-name&gt;*&lt;/ejb-name&gt;
      &lt;interceptor-class&gt;com.myco.ImportantInterceptor&lt;/interceptor-class&gt;
   &lt;/interceptor-binding&gt;
&lt;/assembly-descriptor&gt;
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3374">squid:S3374</a>
					</td>
					<td>
						<details>
							<p>According to the Common Weakness Enumeration,</p>
<blockquote>
  If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the
  other. This decision might not correspond to the programmer's expectations...
</blockquote>
<p>In such a case, it is likely that the two forms should be combined. At the very least, one should be removed.</p>
<h2>Noncompliant Code Example</h2>
<pre>
&lt;form-validation&gt;
  &lt;formset&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;  &lt;!-- Noncompliant --&gt;
  &lt;/formset&gt;
&lt;/form-validation&gt;
</pre>
<h2>Compliant Solution</h2>
<pre>
&lt;form-validation&gt;
  &lt;formset&gt;
    &lt;form name="BookForm"&gt; ... &lt;/form&gt;
  &lt;/formset&gt;
&lt;/form-validation&gt;
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/102.html">MITRE, CWE-102</a> - Struts: Duplicate Validation Forms </li>
  <li> <a href="https://www.owasp.org/index.php/Struts:_Duplicate_Validation_Forms#Struts:_Duplicate_Validation_Forms">OWASP, Improper Data
  Validation</a> - Struts: Duplicate Validation Forms </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:ClassVariableVisibilityCheck">squid:ClassVariableVisibilityCheck</a>
					</td>
					<td>
						<details>
							<p>Public class variable fields do not respect the encapsulation principle and has three main disadvantages:</p>
<ul>
  <li> Additional behavior such as validation cannot be added. </li>
  <li> The internal representation is exposed, and cannot be changed afterwards. </li>
  <li> Member values are subject to change from anywhere in the code and may not meet the programmer's assumptions. </li>
</ul>
<p>By using private attributes and accessor methods (set and get), unauthorized modifications are prevented.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyClass {

  public static final int SOME_CONSTANT = 0;     // Compliant - constants are not checked

  public String firstName;                       // Noncompliant

}
</pre>
<h2>Compliant Solution</h2>
<pre>
public class MyClass {

  public static final int SOME_CONSTANT = 0;     // Compliant - constants are not checked

  private String firstName;                      // Compliant

  public String getFirstName() {
    return firstName;
  }

  public void setFirstName(String firstName) {
    this.firstName = firstName;
  }

}
</pre>
<h2>Exceptions</h2>
<p>Because they are not modifiable, this rule ignores <code>public final</code> fields.</p>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/493.html">MITRE, CWE-493</a> - Critical Public Variable Without Final Modifier </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2089">squid:S2089</a>
					</td>
					<td>
						<details>
							<p>The fields in an HTTP request are putty in the hands of an attacker, and you cannot rely on them to tell you the truth about anything. While it may
be safe to store such values after they have been neutralized, decisions should never be made based on their contents.</p>
<p>This rule flags uses of the referer header field.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public class MyServlet extends HttpServlet {
  protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    String referer = request.getHeader("referer");  // Noncompliant
    if(isTrustedReferer(referer)){
      //..
    }
    //...
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/807">MITRE, CWE-807</a> - Reliance on Untrusted Inputs in a Security Decision </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/293">MITRE, CWE-293</a> - Using Referer Field for Authentication </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">OWASP Top Ten 2013 Category A2</a> -
  Broken Authentication and Session Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S3066">squid:S3066</a>
					</td>
					<td>
						<details>
							<p><code>enum</code>s are generally thought of as constant, but an <code>enum</code> with a <code>public</code> field or <code>public</code> setter is
not only non-constant, but also vulnerable to malicious code. Ideally fields in an <code>enum</code> are <code>private</code> and set in the
constructor, but if that's not possible, their visibility should be reduced as much as possible.</p>
<h2>Noncompliant Code Example</h2>
<pre>
public enum Continent {

  NORTH_AMERICA (23, 24709000),
  // ...
  EUROPE (50, 39310000);

  public int countryCount;  // Noncompliant
  private int landMass;

  Continent(int countryCount, int landMass) {
    // ...
  }

  public void setLandMass(int landMass) {  // Noncompliant
    this.landMass = landMass;
  }
</pre>
<h2>Compliant Solution</h2>
<pre>
public enum Continent {

  NORTH_AMERICA (23, 24709000),
  // ...
  EUROPE (50, 39310000);

  private int countryCount;
  private int landMass;

  Continent(int countryCount, int landMass) {
    // ...
  }
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S899">squid:S899</a>
					</td>
					<td>
						<details>
							<p>When the return value of a function call contain the operation status code, this value should be tested to make sure the operation completed
successfully.</p>
<p>This rule raises an issue when the return values of the following are ignored:</p>
<ul>
  <li> <code>java.io.File</code> operations that return a status code (except <code>mkdirs</code>) </li>
  <li> <code>Iterator.hasNext()</code> </li>
  <li> <code>Enumeration.hasMoreElements()</code> </li>
  <li> <code>Lock.tryLock()</code> </li>
  <li> non-void <code>Condition.await*</code> methods </li>
  <li> <code>CountDownLatch.await(long, TimeUnit)</code> </li>
  <li> <code>Semaphore.tryAcquire</code> </li>
  <li> <code>BlockingQueue</code>: <code>offer</code>, <code>remove</code>, <code>drainTo</code>, </li>
</ul>
<h2>Noncompliant Code Example</h2>
<pre>
public void doSomething(File file, Lock lock) {
  file.delete();  // Noncompliant
  // ...
  lock.tryLock(); // Noncompliant
}
</pre>
<h2>Compliant Solution</h2>
<pre>
public void doSomething(File file, Lock lock) {
  if (!lock.tryLock()) {
    // lock failed; take appropriate action
  }
  if (!file.delete()) {
    // file delete failed; take appropriate action
  }
}
</pre>
<h2>See</h2>
<ul>
  <li> MISRA C:2004, 16.10 - If a function returns error information, then that error information shall be tested </li>
  <li> MISRA C++:2008, 0-1-7 - The value returned by a function having a non-void return type that is not an overloaded operator shall always be used.
  </li>
  <li> MISRA C:2012, Dir. 4.7 - If a function returns error information, then that error information shall be tested </li>
  <li> MISRA C:2012, 17.7 - The value returned by a function having non-void return type shall be used </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/w4C4Ag">CERT, ERR33-C.</a> - Detect and handle standard library errors </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/iIBfBw">CERT, POS54-C.</a> - Detect and handle POSIX library errors </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/9gEqAQ">CERT, EXP00-J.</a> - Do not ignore values returned by methods </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/9YIRAQ">CERT, EXP12-C.</a> - Do not ignore values returned by functions </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/eoAyAQ">CERT, EXP12-CPP.</a> - Do not ignore values returned by functions or methods
  </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/toHWAw">CERT, FIO02-J.</a> - Detect and handle file-related errors </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/754">MITRE, CWE-754</a> - Improper Check for Unusual Exceptional Conditions </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid:S2092">squid:S2092</a>
					</td>
					<td>
						<details>
							<p>The "secure" attribute prevents cookies from being sent over plaintext connections such as HTTP, where they would be easily eavesdropped upon.
Instead, cookies with the secure attribute are only sent over encrypted HTTPS connections.</p>
<h2>Noncompliant Code Example</h2>
<pre>
Cookie c = new Cookie(SECRET, secret);  // Noncompliant; cookie is not secure
response.addCookie(c);
</pre>
<h2>Compliant Solution</h2>
<pre>
Cookie c = new Cookie(SECRET, secret);
c.setSecure(true);
response.addCookie(c);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/614">MITRE, CWE-614</a> - Sensitive Cookie in HTTPS Session Without 'Secure' Attribute </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">OWASP Top Ten 2013 Category A2</a> -
  Broken Authentication and Session Management </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP Top Ten 2013 Category A6</a> - Sensitive Data Exposure
  </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPRING_FILE_DISCLOSURE">findsecbugs:SPRING_FILE_DISCLOSURE</a>
					</td>
					<td>
						<details>
							<p>
Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories.<br/>
An attacker may be able to forge a request parameter to match sensitive file locations. For example, requesting "http://example.com/?returnURL=WEB-INF/applicationContext.xml" would display the application's applicationContext.xml file. The attacker would be able to locate and download the applicationContext.xml referenced in the other configuration files, and even class files or jar files, obtaining sensitive information and launching other types of attacks.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>... 
String returnURL = request.getParameter("returnURL");
return new ModelAndView(returnURL); 
...</pre>
</p>
<p>
    <b>Solution:</b><br/>
Avoid constructing server-side redirects using user controlled input.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/552.html">CWE-552: Files or Directories Accessible to External Parties</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WEAK_MESSAGE_DIGEST_SHA1">findsecbugs:WEAK_MESSAGE_DIGEST_SHA1</a>
					</td>
					<td>
						<details>
							<p>The algorithms SHA-1 is not a recommended algorithm for hash password, for signature verification and other
uses. <b>PBKDF2</b> should be used to hash password for example.</p>

<blockquote>
    "<b>SHA-1 for digital signature generation:</b><br/>
    SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance.
    For all other applications, <u>SHA-1 shall not be used for digital signature generation</u>.<br/>
    <b>SHA-1 for digital signature verification:</b><br/>
    For digital signature verification, <u>SHA-1 is allowed for legacy-use</u>.<br/>
    [...]<br/>
    <b>SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256</b>:<br/>
    The use of these hash functions is acceptable for all hash function applications."<br/>
    - <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15</a>
</blockquote>
<blockquote>
    "The main idea of a PBKDF is to slow dictionary or brute force attacks on the passwords by increasing the time
    needed to test each password. An attacker with a list of likely passwords can evaluate the PBKDF using the known
    iteration counter and the salt. Since an attacker has to spend a significant amount of computing time for each try,
    it becomes harder to apply the dictionary or brute force attacks."<br/>
- <a href="http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf">NIST: Recommendation for Password-Based Key Derivation  p.12</a>

</blockquote>
<br/>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>MessageDigest sha1Digest = MessageDigest.getInstance("SHA1");
    sha1Digest.update(password.getBytes());
    byte[] hashValue = sha1Digest.digest();</pre>
    <br/>
    <pre>byte[] hashValue = DigestUtils.getSha1Digest().digest(password.getBytes());</pre>
</p>
<br/>
<p>
    <b>Solution (Using bouncy castle):</b><br/>
    <pre>public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
    gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096);
    return ((KeyParameter) gen.generateDerivedParameters(256)).getKey();
}</pre>
    <br/>
    <b>Solution (Java 8 and later):</b><br/>
    <pre>public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8);
    SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
    return f.generateSecret(spec).getEncoded();
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know">Qualys blog: SHA1 Deprecation: What You Need to Know</a><br/>
<a href="https://googleonlinesecurity.blogspot.ca/2014/09/gradually-sunsetting-sha-1.html">Google Online Security Blog: Gradually sunsetting SHA-1</a><br/>
<a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths</a><br/>
<a href="http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf">NIST: Recommendation for Password-Based Key Derivation</a><br/>
<a href="http://stackoverflow.com/questions/22580853/reliable-implementation-of-pbkdf2-hmac-sha256-for-java">Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java</a><br/>
<a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XSS_REQUEST_WRAPPER">findsecbugs:XSS_REQUEST_WRAPPER</a>
					</td>
					<td>
						<details>
							<p>
An implementation of <code>HttpServletRequestWrapper</code> called <code>XSSRequestWrapper</code> was published through
various blog sites. <sup><a href="http://java.dzone.com/articles/stronger-anti-cross-site">[1]</a></sup>
<sup><a href="http://www.javacodegeeks.com/2012/07/anti-cross-site-scripting-xss-filter.html">[2]</a></sup>
</p>
<p>
The filtering is weak for a few reasons:
<ul>
<li>It covers only parameters not headers and side-channel inputs</li>
<li>The replace chain can be bypassed easily (see example below)</li>
<li>It's a black list of very specific bad patterns (rather than a white list of good/valid input)</li>
</ul>
</p>
<p>
<b>Example of bypass:</b><br/>
</p>
<pre>&lt;scrivbscript:pt&gt;alert(1)&lt;/scrivbscript:pt&gt;</pre>
<p>
The previous input will be transformed into <b><code>"&lt;script&gt;alert(1)&lt;/script&gt;"</code></b>.
The removal of <code>"vbscript:"</code> is after the replacement of <code>"&lt;script&gt;.*&lt;/script&gt;"</code>.
</p>
<p>
For stronger protection, choose a solution that encodes characters automatically in the <b><u>view</u></b> (template, jsp, ...) following
the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">WASC-8: Cross Site Scripting</a><br/>
<a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">OWASP: XSS Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)</a><br/>
<a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:NULL_CIPHER">findsecbugs:NULL_CIPHER</a>
					</td>
					<td>
						<details>
							<p>
The NullCipher is rarely used intentionally in production applications. It implements the Cipher interface by returning ciphertext 
identical to the supplied plaintext. In a few contexts, such as testing, a NullCipher may be appropriate.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>Cipher doNothingCihper = new NullCipher();
[...]
//The ciphertext produced will be identical to the plaintext.
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
    <b>Solution:</b><br/>
    Avoid using the NullCipher. Its accidental use can introduce a significant confidentiality risk.
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:COOKIE_PERSISTENT">findsecbugs:COOKIE_PERSISTENT</a>
					</td>
					<td>
						<details>
							<p>
Storing sensitive data in a persistent cookie for an extended period of time can lead to a breach of confidentiality or account compromise. 
</p>
<p>
    <b>Explanation:</b><br/>
If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information.<br/>
Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
</p>
<p>
    <b>Vulnerable Code:</b> The following code sets a cookie to expire in 1 year.<br/>
<pre>[...]
Cookie cookie = new Cookie("email", email);
cookie.setMaxAge(60*60*24*365);
[...]</pre>
</p>
<p>
    <b>Solution:</b><br/>
<ul>
    <li>Use persistent cookies only if necessary and limit their maximum age.</li>
    <li>Don't use persistent cookies for sensitive data.</li>
</ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/Cookie.html#setMaxAge%28int%29">Class Cookie setMaxAge documentation</a><br/>
<a href="https://cwe.mitre.org/data/definitions/539.html">CWE-539: Information Exposure Through Persistent Cookies</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:CUSTOM_MESSAGE_DIGEST">findsecbugs:CUSTOM_MESSAGE_DIGEST</a>
					</td>
					<td>
						<details>
							<p>Implementing a custom MessageDigest is error-prone.</p>
<p><a href="http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html">NIST</a> recommends the use of SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256.</p>
<blockquote>
    "<b>SHA-1 for digital signature generation:</b><br/>
    SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance.
    For all other applications, <u>SHA-1 shall not be used for digital signature generation</u>.<br/>
    <b>SHA-1 for digital signature verification:</b><br/>
    For digital signature verification, <u>SHA-1 is allowed for legacy-use</u>.<br/>
    [...]<br/>
    <b>SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256</b>:<br/>
    The use of these hash functions is acceptable for all hash function applications."<br/>
    - <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15</a>
</blockquote>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>MyProprietaryMessageDigest extends MessageDigest {
    @Override
    protected byte[] engineDigest() {
        [...]
        //Creativity is a bad idea
        return [...];
    }
}</pre>
</p>
<p>
<p>Upgrade your implementation to use one of the approved algorithms. Use an algorithm that is sufficiently strong for your specific security needs.</p>
<p>
    <b>Example Solution:</b><br/>
<pre>MessageDigest sha256Digest = MessageDigest.getInstance("SHA256");
sha256Digest.update(password.getBytes());</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html">NIST Approved Hashing Algorithms</a><br/>
<a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PLAY_UNVALIDATED_REDIRECT">findsecbugs:PLAY_UNVALIDATED_REDIRECT</a>
					</td>
					<td>
						<details>
							<p>
    Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied
    parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
</p>
<p>
    <b>Scenario</b><br/>
    1. A user is tricked into visiting the malicious URL: <code>http://website.com/login?redirect=http://evil.vvebsite.com/fake/login</code><br/>
    2. The user is redirected to a fake login page that looks like a site they trust. (<code>http://evil.vvebsite.com/fake/login</code>)<br/>
    3. The user enters his credentials.<br/>
    4. The evil site steals the user's credentials and redirects him to the original website.<br/>
    <br/>
    This attack is plausible because most users don't double check the URL after the redirection. Also, redirection to
    an authentication page is very common.
</p>
<p>
    <b>Vulnerable Code:</b></br/>
    <pre>def login(redirectUrl:String) = Action {
    [...]
    Redirect(url)
}</pre>
</p>
<p>
    <b>Solution/Countermeasures:</b><br/>
    <ul>
        <li>Don't accept redirection destinations from users</li>
        <li>Accept a destination key, and use it to look up the target (legal) destination</li>
        <li>Accept only relative paths</li>
        <li>White list URLs (if possible)</li>
        <li>Validate that the beginning of the URL is part of a white list</li>
    </ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse">WASC-38: URL Redirector Abuse</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards">OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards</a><br/>
<a href="https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet">OWASP: Unvalidated Redirects and Forwards Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/601.html">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:LDAP_ENTRY_POISONING">findsecbugs:LDAP_ENTRY_POISONING</a>
					</td>
					<td>
						<details>
							<p>
JNDI API support the binding of serialize object in LDAP directories. If certain attributes are presented, the deserialization
of object will be made in the application querying the directory (See Black Hat USA 2016 white paper for details).
Object deserialization should be threated as risky operation that can lead to remote code execution.
</p>
<p>
The exploitation of the vulnerability will be possible if the attacker has an entry point in an LDAP base query, by adding
attributes to an existing LDAP entry or by configuring the application to use a malicious LDAP server.
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>
DirContext ctx = new InitialDirContext();
//[...]

ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            true, //Enable object deserialization if bound in directory
            deref));
</pre>
</p>
<p>
    <b>Solution:</b>
<pre>
DirContext ctx = new InitialDirContext();
//[...]

ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            false, //Disable
            deref));
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf">Black Hat USA 2016: A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land</a>
(<a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf">slides</a> &amp; <a href="https://www.youtube.com/watch?v=Y8a5nB-vy78">video</a>) by Alvaro Mu&#xF1;oz and Oleksandr Mirosh<br/>
<a href="https://community.hpe.com/t5/Security-Research/Introducing-JNDI-Injection-and-LDAP-Entry-Poisoning/ba-p/6885118">HP Enterprise: Introducing JNDI Injection and LDAP Entry Poisoning</a> by Alvaro Mu&#xF1;oz<br/>
<a href="http://blog.trendmicro.com/trendlabs-security-intelligence/new-headaches-how-the-pawn-storm-zero-day-evaded-javas-click-to-play-protection/">TrendMicro: How The Pawn Storm Zero-Day Evaded Java's Click-to-Play Protection</a> by Jack Tang
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_HEADER_REFERER">findsecbugs:SERVLET_HEADER_REFERER</a>
					</td>
					<td>
						<details>
							<p>
Behavior:
<ul>
<li>Any value can be assigned to this header if the request is coming from a malicious user.</li>
<li>The "Referer" will not be present if the request was initiated from another origin that is secure (https).</li>
</ul>
</p>
<p>
Recommendations:
<ul>
<li>No access control should be based on the value of this header.</li>
<li>No CSRF protection should be based only on this value (<a href="http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14">because it is optional</a>).</li>
</ul>
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/807.html">CWE-807: Untrusted Inputs in a Security Decision</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HARD_CODE_KEY">findsecbugs:HARD_CODE_KEY</a>
					</td>
					<td>
						<details>
							<p>
Cryptographic keys should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is
certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
(Hard coded passwords are reported separately by <i>Hard Coded Password</i> pattern)
</p>
<p>
<p><b>Vulnerable Code:</b><br/>

<pre>byte[] key = {1, 2, 3, 4, 5, 6, 7, 8};
SecretKeySpec spec = new SecretKeySpec(key, "AES");
Cipher aes = Cipher.getInstance("AES");
aes.init(Cipher.ENCRYPT_MODE, spec);
return aesCipher.doFinal(secretData);</pre> 
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/321.html">CWE-321: Use of Hard-coded Cryptographic Key</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPRING_CSRF_UNRESTRICTED_REQUEST_MAPPING">findsecbugs:SPRING_CSRF_UNRESTRICTED_REQUEST_MAPPING</a>
					</td>
					<td>
						<details>
							<p>Methods annotated with <code>RequestMapping</code> are by default mapped to all the HTTP request methods.
However, Spring Security's CSRF protection is not enabled by default
for the HTTP request methods <code>GET</code>, <code>HEAD</code>, <code>TRACE</code>, and <code>OPTIONS</code>
(as this could cause the tokens to be leaked).
Therefore, state-changing methods annotated with <code>RequestMapping</code> and not narrowing the mapping
to the HTTP request methods <code>POST</code>, <code>PUT</code>, <code>DELETE</code>, or <code>PATCH</code>
are vulnerable to CSRF attacks.</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>@Controller
public class UnsafeController {

    @RequestMapping("/path")
    public void writeData() {
        // State-changing operations performed within this method.
    }
}</pre>
</p>
<p>
    <b>Solution (Spring Framework 4.3 and later):</b><br/>
<pre>@Controller
public class SafeController {

    /**
     * For methods without side-effects use @GetMapping.
     */
    @GetMapping("/path")
    public String readData() {
        // No state-changing operations performed within this method.
        return "";
    }

    /**
     * For state-changing methods use either @PostMapping, @PutMapping, @DeleteMapping, or @PatchMapping.
     */
    @PostMapping("/path")
    public void writeData() {
        // State-changing operations performed within this method.
    }
}</pre>
</p>
<p>
    <b>Solution (Before Spring Framework 4.3):</b><br/>
<pre>@Controller
public class SafeController {

    /**
     * For methods without side-effects use either
     * RequestMethod.GET, RequestMethod.HEAD, RequestMethod.TRACE, or RequestMethod.OPTIONS.
     */
    @RequestMapping(value = "/path", method = RequestMethod.GET)
    public String readData() {
        // No state-changing operations performed within this method.
        return "";
    }

    /**
     * For state-changing methods use either
     * RequestMethod.POST, RequestMethod.PUT, RequestMethod.DELETE, or RequestMethod.PATCH.
     */
    @RequestMapping(value = "/path", method = RequestMethod.POST)
    public void writeData() {
        // State-changing operations performed within this method.
    }
}</pre>
</p>
<p>
<b>References</b><br/>
<a href="https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html#csrf-use-proper-verbs">Spring Security Official Documentation: Use proper HTTP verbs (CSRF protection)</a><br/>
<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">OWASP: Cross-Site Request Forgery</a><br/>
<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet">OWASP: CSRF Prevention Cheat Sheet</a><br/>
<a href="https://cwe.mitre.org/data/definitions/352.html">CWE-352: Cross-Site Request Forgery (CSRF)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPEL_INJECTION">findsecbugs:SPEL_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
    A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid
    that unfiltered values fall into this risky code evaluation.
</p>
<p><b>Code at risk:</b></p>
<p>
<pre>
public void parseExpressionInterface(Person personObj,String property) {

        ExpressionParser parser = new SpelExpressionParser();

        //Unsafe if the input is control by the user..
        Expression exp = parser.parseExpression(property+" == 'Albert'");

        StandardEvaluationContext testContext = new StandardEvaluationContext(personObj);
        boolean result = exp.getValue(testContext, Boolean.class);
[...]</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/95.html">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a><br/>
    <a href="http://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/expressions.html">Spring Expression Language (SpEL) - Official Documentation</a><br/>
    <a href="https://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf">Minded Security: Expression Language Injection</a><br/>
    <a href="http://blog.h3xstream.com/2014/11/remote-code-execution-by-design.html">Remote Code Execution .. by design</a>: Example of malicious payload. The samples given could be used to test sandboxing rules.<br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WEAK_MESSAGE_DIGEST_MD5">findsecbugs:WEAK_MESSAGE_DIGEST_MD5</a>
					</td>
					<td>
						<details>
							<p>The algorithms MD2, MD4 and MD5 are not a recommended MessageDigest. <b>PBKDF2</b> should be used to hash password for example.</p>

<blockquote>
    "The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions
    within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 2<sup>24.1</sup>).[1] Further, there is also a
    chosen-prefix collision attack that can produce a collision for two inputs with specified prefixes within hours, using
    off-the-shelf computing hardware (complexity 2<sup>39</sup>).[2]"<br/>
    - <a href="https://en.wikipedia.org/wiki/MD5#Security">Wikipedia: MD5 - Security</a>
</blockquote>

<blockquote>
    "<b>SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256</b>:<br/>
    The use of these hash functions is acceptable for all hash function applications."<br/>
    - <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.15</a>
</blockquote>
<blockquote>
    "The main idea of a PBKDF is to slow dictionary or brute force attacks on the passwords by increasing the time
    needed to test each password. An attacker with a list of likely passwords can evaluate the PBKDF using the known
    iteration counter and the salt. Since an attacker has to spend a significant amount of computing time for each try,
    it becomes harder to apply the dictionary or brute force attacks."<br/>
- <a href="http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf">NIST: Recommendation for Password-Based Key Derivation  p.12</a>
</blockquote>
<br/>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>MessageDigest md5Digest = MessageDigest.getInstance("MD5");
    md5Digest.update(password.getBytes());
    byte[] hashValue = md5Digest.digest();</pre>
    <br/>
    <pre>byte[] hashValue = DigestUtils.getMd5Digest().digest(password.getBytes());</pre>
</p>
<br/>
<p>
    <b>Solution (Using bouncy castle):</b><br/>
    <pre>public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    PKCS5S2ParametersGenerator gen = new PKCS5S2ParametersGenerator(new SHA256Digest());
    gen.init(password.getBytes("UTF-8"), salt.getBytes(), 4096);
    return ((KeyParameter) gen.generateDerivedParameters(256)).getKey();
}</pre>
    <br/>
    <b>Solution (Java 8 and later):</b><br/>
    <pre>public static byte[] getEncryptedPassword(String password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 4096, 256 * 8);
    SecretKeyFactory f = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
    return f.generateSecret(spec).getEncoded();
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
[1] <a href="http://www.win.tue.nl/hashclash/On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf">On Collisions for MD5</a>: Master Thesis by M.M.J. Stevens<br/>
[2] <a href="http://homepages.cwi.nl/~stevens/papers/stJOC%20-%20Chosen-Prefix%20Collisions%20for%20MD5%20and%20Applications.pdf">Chosen-prefix collisions for MD5 and applications</a>: Paper written by Marc Stevens<br/>
<a href="https://en.wikipedia.org/wiki/MD5">Wikipedia: MD5</a><br/>
<a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths</a><br/>
<a href="http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf">NIST: Recommendation for Password-Based Key Derivation</a><br/>
<a href="http://stackoverflow.com/questions/22580853/reliable-implementation-of-pbkdf2-hmac-sha256-for-java">Stackoverflow: Reliable implementation of PBKDF2-HMAC-SHA256 for Java</a><br/>
<a href="http://cwe.mitre.org/data/definitions/327.html">CWE-327: Use of a Broken or Risky Cryptographic Algorithm</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:TAPESTRY_ENDPOINT">findsecbugs:TAPESTRY_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>A Tapestry endpoint was discovered at application startup. Tapestry apps are structured with a backing Java class and a corresponding 
Tapestry Markup Language page (a .tml file) for each page. When a request is received, the GET/POST parameters are mapped to specific 
inputs in the backing Java class. The mapping is either done with fieldName:</p>
<pre><code>
    [...]
    protected String input;
    [...]
</code></pre>
<p>or the definition of an explicit annotation:
</p>
<pre><code>
    [...]
    @org.apache.tapestry5.annotations.Parameter
    protected String parameter1;

    @org.apache.tapestry5.annotations.Component(id = "password")
    private PasswordField passwordField;
    [...]
</code></pre>
<p>The page is mapped to the view <code>[/resources/package/PageName].tml.</code></p>
<p>Each Tapestry page in this application should be researched to make sure all inputs that are automatically 
mapped in this way are properly validated before they are used.</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://tapestry.apache.org/">Apache Tapestry Home Page</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PERMISSIVE_CORS">findsecbugs:PERMISSIVE_CORS</a>
					</td>
					<td>
						<details>
							<p>
Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, cull through it, and communicate it back to the attacker. HTML5 makes it possible for JavaScript to access data across domains if a new HTTP header called Access-Control-Allow-Origin is defined. With this header, a Web server defines which other domains are allowed to access its domain using cross-origin requests. However, caution should be taken when defining the header because an overly permissive CORS policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay and other attacks.
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>response.addHeader("Access-Control-Allow-Origin", "*");</pre>
</p>
<p>
    <b>Solution:</b>
<br/>
Avoid using * as the value of the Access-Control-Allow-Origin header, which indicates that the application's data is accessible to JavaScript running on any domain.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.w3.org/TR/cors/">W3C Cross-Origin Resource Sharing</a><br/>
<a href="http://enable-cors.org/">Enable Cross-Origin Resource Sharing</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SEAM_LOG_INJECTION">findsecbugs:SEAM_LOG_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
    Seam Logging API support an expression language to introduce bean property to log messages. The expression language can
    also be the source to unwanted code execution.
</p>
<p>
    In this context, an expression is built with a dynamic value. The source of the value(s) should be verified to avoid
    that unfiltered values fall into this risky code evaluation.
</p>
<p><b>Code at risk:</b></p>
<p>
<pre>public void logUser(User user) {
    log.info("Current logged in user : " + user.getUsername());
    //...
}</pre>
</p>
<p><b>Solution:</b></p>
<p>
<pre>public void logUser(User user) {
    log.info("Current logged in user : #0", user.getUsername());
    //...
}</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://issues.jboss.org/browse/JBSEAM-5130">JBSEAM-5130: Issue documenting the risk</a><br/>
    <a href="https://docs.jboss.org/seam/2.3.1.Final/reference/html_single/#d0e4185">JBoss Seam: Logging (Official documentation)</a><br/>
    <a href="https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html">The Java EE 6 Tutorial: Expression Language</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/95.html">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a><br/>

</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HTTP_RESPONSE_SPLITTING">findsecbugs:HTTP_RESPONSE_SPLITTING</a>
					</td>
					<td>
						<details>
							<p>
    When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream
    that is interpreted as two different HTTP responses (instead of one).
    An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks.
    According to OWASP, the issue has been fixed in virtually all modern Java EE application servers, but it is still better to validate the input.
    If you are concerned about this risk, you should test on the platform of concern to see
    if the underlying platform allows for CR or LF characters to be injected into headers.
    This weakness is reported with lower priority than SQL injection etc.,
    if you are using a vulnerable platform, please check low-priority warnings too.
</p>
<br/>
<p>
<b>Code at risk:</b><br/>
<pre>String author = request.getParameter(AUTHOR_PARAMETER);
// ...
Cookie cookie = new Cookie("author", author);
response.addCookie(cookie);</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">OWASP: HTTP Response Splitting</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/113.html">CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')</a>
    <a href="http://cwe.mitre.org/data/definitions/93.html">CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PATH_TRAVERSAL_OUT">findsecbugs:PATH_TRAVERSAL_OUT</a>
					</td>
					<td>
						<details>
							<p>A file is opened to write to its contents. The filename comes from an <b>input</b> parameter. 
If an unfiltered parameter is passed to this file API, files at an arbitrary filesystem location could be modified.</p>
<p>This rule identifies <b>potential</b> path traversal vulnerabilities. In many cases, the constructed file path cannot be controlled
by the user. If that is the case, the reported instance is a false positive.</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC-33: Path Traversal</a><br/>
<a href="https://www.owasp.org/index.php/Path_Traversal">OWASP: Path Traversal</a><br/>
<a href="http://capec.mitre.org/data/definitions/126.html">CAPEC-126: Path Traversal</a><br/>
<a href="http://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WEAK_TRUST_MANAGER">findsecbugs:WEAK_TRUST_MANAGER</a>
					</td>
					<td>
						<details>
							<p>Empty TrustManager implementations are often used to connect easily to a host that is not signed by a root
<a href="http://en.wikipedia.org/wiki/Certificate_authority">certificate authority</a>. As a consequence, this is vulnerable to
<a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">Man-in-the-middle attacks</a>
since the client will trust any certificate.
</p>
<p>
A TrustManager allowing specific certificates (based on a truststore for example) should be built.
Detailed information for a proper implementation is available at:
<a href="http://stackoverflow.com/a/6378872/89769">[1]</a> 
<a href="http://stackoverflow.com/a/5493452/89769">[2]</a>
</p>
<br/>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>class TrustAllManager implements X509TrustManager {

    @Override
    public void checkClientTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        //Trust any client connecting (no certificate validation)
    }

    @Override
    public void checkServerTrusted(X509Certificate[] x509Certificates, String s) throws CertificateException {
        //Trust any remote server (no certificate validation)
    }

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }
}</pre>
</p>
<br/>
<p>
    <b>Solution (TrustMangager based on a keystore):</b><br/>
<pre>KeyStore ks = //Load keystore containing the certificates trusted

SSLContext sc = SSLContext.getInstance("TLS");

TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);

sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/295.html">CWE-295: Improper Certificate Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:RSA_NO_PADDING">findsecbugs:RSA_NO_PADDING</a>
					</td>
					<td>
						<details>
							<p>
The software uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
</p>
<p>
<b>Vulnerable Code:</b><br/>
<pre>Cipher.getInstance("RSA/NONE/NoPadding")</pre>
</p>
<p>
<b>Solution:</b><br/>
The code should be replaced with:<br/>
<pre>Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding")</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/780.html">CWE-780: Use of RSA Algorithm without OAEP</a><br/>
<a href="http://rdist.root.org/2009/10/06/why-rsa-encryption-padding-is-critical/">Root Labs: Why RSA encryption padding is critical</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:URL_REWRITING">findsecbugs:URL_REWRITING</a>
					</td>
					<td>
						<details>
							<p>
The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL.<br/>
URL rewriting has significant security risks. Since session ID appears in the URL, it may be easily seen by third parties. Session ID in the URL can be disclosed in many ways, for example:<br/>
<ul>
    <li>Log files,</li>
    <li>The browser history,</li>
    <li>By copy-and-pasting it into an e-mail or posting,</li>
    <li>The HTTP Referrer.</li>
</ul>
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>out.println("Click &lt;a href=" + 
                res.encodeURL(HttpUtils.getRequestURL(req).toString()) + 
                "&gt;here&lt;/a&gt;");</pre>
</p>
<p>
    <b>Solution:</b><br/>
Avoid using those methods. If you are looking to encode a URL String or form parameters do not confuse the URL rewriting methods with the URLEncoder class.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Top_10_2010-A3-Broken_Authentication_and_Session_Management">OWASP Top 10 2010-A3-Broken Authentication and Session Management</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:INSECURE_COOKIE">findsecbugs:INSECURE_COOKIE</a>
					</td>
					<td>
						<details>
							<p>
A new cookie is created without the <code>Secure</code> flag set.
The <code>Secure</code> flag is a directive to the browser to make sure that the cookie is not sent for insecure
communication (<code>http://</code>).
</p>

<p>
<b>Code at risk:</b><br/>
<pre>
Cookie cookie = new Cookie("userName",userName);
response.addCookie(cookie);
</pre>
</p>

<p>
<b>Solution (Specific configuration):</b><br/>
<pre>
Cookie cookie = new Cookie("userName",userName);
cookie.setSecure(true); // Secure flag
cookie.setHttpOnly(true);
</pre>
</p>

<p>
<b>Solution (Servlet 3.0 configuration):</b><br/>
<pre>
&lt;web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0"&gt;
[...]
&lt;session-config&gt;
 &lt;cookie-config&gt;
  &lt;http-only&gt;true&lt;/http-only&gt;
  &lt;secure&gt;true&lt;/secure&gt;
 &lt;/cookie-config&gt;
&lt;/session-config&gt;
&lt;/web-app&gt;
</pre>
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="https://cwe.mitre.org/data/definitions/614.html">CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute</a><br/>
<a href="https://cwe.mitre.org/data/definitions/315.html">CWE-315: Cleartext Storage of Sensitive Information in a Cookie</a><br/>
<a href="https://cwe.mitre.org/data/definitions/311.html">CWE-311: Missing Encryption of Sensitive Data</a><br/>
<a href="https://www.owasp.org/index.php/SecureFlag">OWASP: Secure Flag</a><br/>
<a href="https://www.rapid7.com/db/vulnerabilities/http-cookie-secure-flag">Rapid7: Missing Secure Flag From SSL Cookie</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT_INTERFACE">findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT_INTERFACE</a>
					</td>
					<td>
						<details>
							<p>
    The use of JavaScript Interface could expose the WebView to risky API. If an XSS is triggered in the WebView, the class
    could be called by the malicious JavaScript code.
</p>

<p>
    <b>Code at risk:</b><br/>
    <pre>
WebView myWebView = (WebView) findViewById(R.id.webView);

myWebView.addJavascriptInterface(new FileWriteUtil(this), "fileWriteUtil");

WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);

[...]
class FileWriteUtil {
    Context mContext;

    FileOpenUtil(Context c) {
        mContext = c;
    }

    public void writeToFile(String data, String filename, String tag) {
        [...]
    }
}
    </pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface%28java.lang.Object,%20java.lang.String%29">Android Official Doc: WebView.addJavascriptInterface()</a><br/>
    <a href="https://cwe.mitre.org/data/definitions/749.html">CWE-749: Exposed Dangerous Method or Function</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:REDOS">findsecbugs:REDOS</a>
					</td>
					<td>
						<details>
							<p>
    Regular expressions (regexs) are frequently subject to Denial of Service (DOS) attacks (called ReDOS). This is due to the fact that regex engines 
    may take a large amount of time when analyzing certain strings, depending on how the regex is defined.
<p>
    For example, for the regex: <b>^(a+)+$</b>, the input "<code>aaaaaaaaaaaaaaaaX</code>" will cause the regex engine to analyze 65536 
different paths.<sup>[1] Example taken from OWASP references</sup></p>
<p>
Therefore, it is possible that a single request may cause a large amount of computation on the server side. 
The problem with this regex, and others like it, is that there are two different ways the same input character can be accepted by the 
Regex due to the + (or a *) inside the parenthesis, and the + (or a *) outside the parenthesis. The way this is written, either + could 
consume the character 'a'. To fix this, the regex should be rewritten to eliminate the ambiguity. For example, this could simply be 
rewritten as: <b>^a+$</b>, which is presumably what the author meant anyway (any number of a's). Assuming that's what the original 
regex meant, this new regex can be evaluated quickly, and is not subject to ReDOS.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://www.jroller.com/sebastianKuebeck/entry/detecting_and_preventing_redos_vulnerabilities">Sebastian Kubeck's Weblog: Detecting and Preventing ReDoS Vulnerabilities</a><br/>
<sup>[1]</sup> <a href="https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS">OWASP: Regular expression Denial of Service</a><br/>
<a href="http://cwe.mitre.org/data/definitions/400.html">CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:BLOWFISH_KEY_SIZE">findsecbugs:BLOWFISH_KEY_SIZE</a>
					</td>
					<td>
						<details>
							<p>
The Blowfish cipher supports keysizes from 32 bits to 448 bits. A small key size makes the ciphertext vulnerable to brute force attacks.
At least 128 bits of entropy should be used when generating the key if use of Blowfish is required.
</p>
<p>
If the algorithm can be changed, the AES block cipher should be used instead.
</p>

<p><b>Vulnerable Code:</b><br/>
<pre>KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
keyGen.init(64);</pre>
</p>

<p><b>Solution:</b><br/>
<pre>KeyGenerator keyGen = KeyGenerator.getInstance("Blowfish");
keyGen.init(128);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://en.wikipedia.org/wiki/Blowfish_(cipher)">Blowfish (cipher)</a><br/>
<a href="http://cwe.mitre.org/data/definitions/326.html">CWE-326: Inadequate Encryption Strength</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:TEMPLATE_INJECTION_FREEMARKER">findsecbugs:TEMPLATE_INJECTION_FREEMARKER</a>
					</td>
					<td>
						<details>
							<p>
Freemarker template engine is powerful. It is possible to add logic including condition statements, loops and external calls.
It is not design to be sandbox to templating operations. A malicious user in control of a template can run malicious code
on the server-side. Freemarker templates should be seen as scripts.
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>Template template = cfg.getTemplate(inputTemplate);
[...]
template.process(data, swOut);</pre>
</p>
<p>
    <b>Solution:</b>
<br/>
Avoid letting end users manipulate templates with Freemarker. If you need to expose template editing to your users,
prefer logic-less template engines such as Handlebars or Moustache (See references).
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://blog.portswigger.net/2015/08/server-side-template-injection.html">PortSwigger: Server-Side Template Injection </a><br/>
<a href="https://jknack.github.io/handlebars.java/">Handlebars.java</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:OBJECT_DESERIALIZATION">findsecbugs:OBJECT_DESERIALIZATION</a>
					</td>
					<td>
						<details>
							<p>
    Object deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows
    the trigger of malicious operation.
</p>
<p>
    Libraries developers tend to fix class that provided potential malicious trigger. There are still classes that are
    known to trigger Denial of Service<sup>[1]</sup>.
</p>
<p>
    Deserialization is a sensible operation that has a great history of vulnerabilities. The web application might
    become vulnerable as soon as a new vulnerability is found in the Java Virtual Machine<sup>[2] [3]</sup>.
</p>

<p>
<b>Code at risk:</b><br/>
<pre>
public UserData deserializeObject(InputStream receivedFile) throws IOException, ClassNotFoundException {

    try (ObjectInputStream in = new ObjectInputStream(receivedFile)) {
        return (UserData) in.readObject();
    }
}
</pre>
</p>

<p>
<b>Solutions:</b><br/>
<p>
Avoid deserializing object provided by remote users.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/502.html">CWE-502: Deserialization of Untrusted Data</a><br/>
<a href="https://www.owasp.org/index.php/Deserialization_of_untrusted_data">Deserialization of untrusted data</a><br/>
<a href="http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8">Serialization and Deserialization </a><br/>
<a href="https://github.com/frohoff/ysoserial">A tool for generating payloads that exploit unsafe Java object deserialization</a><br/>
[1] <a href="https://gist.github.com/coekie/a27cc406fc9f3dc7a70d">Example of Denial of Service using the class java.util.HashSet</a><br/>
[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-2590">OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)</a><br/>
[3] <a href="https://www.rapid7.com/db/modules/exploit/multi/browser/java_calendar_deserialize">Rapid7: Sun Java Calendar Deserialization Privilege Escalation (CVE-2008-5353)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_JPA">findsecbugs:SQL_INJECTION_JPA</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>
EntityManager pm = getEM();

TypedQuery&lt;UserEntity&gt; q = em.createQuery(
    String.format("select * from Users where name = %s", username),
    UserEntity.class);

UserEntity res = q.getSingleResult();</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>
TypedQuery&lt;UserEntity&gt; q = em.createQuery(
    "select * from Users where name = usernameParam",UserEntity.class)
    .setParameter("usernameParam", username);

UserEntity res = q.getSingleResult();</pre>
</p>
<br/>
<p>
<b>References (JPA)</b><br/>
<a href="http://docs.oracle.com/javaee/6/tutorial/doc/bnbrg.html">The Java EE 6 Tutorial: Creating Queries Using the Java Persistence Query Language</a><br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_HEADER">findsecbugs:SERVLET_HEADER</a>
					</td>
					<td>
						<details>
							<p>Request headers can easily be altered by the requesting user. In general, no assumption should be made that 
the request came from a regular browser without modification by an attacker. As such, it is recommended that you 
not trust this value in any security decisions you make with respect to a request.</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/807.html">CWE-807: Untrusted Inputs in a Security Decision</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:JACKSON_UNSAFE_DESERIALIZATION">findsecbugs:JACKSON_UNSAFE_DESERIALIZATION</a>
					</td>
					<td>
						<details>
							<p>When the Jackson databind library is used incorrectly the deserialization of untrusted data can lead to remote code execution, if there is a class in classpath that allows the trigger of malicious operation.

<p>
<b>Solutions:</b><br/>
<p>
Explicitly define what types and subtypes you want to be available when using polymorphism through JsonTypeInfo.Id.NAME.
Also, never call ObjectMapper.<strong>enableDefaultTyping</strong> (and then readValue a type that holds a Object or Serializable or Comparable or a known deserialization type).
</p>

<p>
<b>Code at risk:</b><br/>
<pre>
public class Example {
    static class ABean {
        public int id;
        public Object obj;
    }

    static class AnotherBean {
        @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS) // or JsonTypeInfo.Id.MINIMAL_CLASS
        public Object obj;
    }

    public void example(String json) throws JsonMappingException {
         ObjectMapper mapper = new ObjectMapper();
         mapper.enableDefaultTyping();
         mapper.readValue(json, ABean.class);
    }

    public void exampleTwo(String json) throws JsonMappingException {
         ObjectMapper mapper = new ObjectMapper();
         mapper.readValue(json, AnotherBean.class);
    }

}
</pre>
</p>

<p>
<b>References</b><br/>
<a href="https://github.com/FasterXML/jackson-databind/issues/1599">Jackson Deserializer security vulnerability</a><br>
<a href="https://github.com/mbechler/marshalsec">Java Unmarshaller Security - Turning your data into code execution</a><br>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:LDAP_INJECTION">findsecbugs:LDAP_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
Just like SQL, all inputs passed to an LDAP query need to be passed in safely. Unfortunately, LDAP doesn't have prepared statement interfaces like SQL.
Therefore, the primary defense against LDAP injection is strong input validation of any untrusted data before including it in an LDAP query.
</p>
<p>
    <b>Code at risk:</b><br/>
    <pre>NamingEnumeration&lt;SearchResult&gt; answers = context.search("dc=People,dc=example,dc=com",
        "(uid=" + username + ")", ctrls);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246947/LDAP%20Injection">WASC-29: LDAP Injection</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/90.html">CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')</a><br/>
<a href="http://www.veracode.com/security/ldap-injection">LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XSS_SERVLET">findsecbugs:XSS_SERVLET</a>
					</td>
					<td>
						<details>
							<p>
A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references)
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    String input1 = req.getParameter("input1");
    [...]
    resp.getWriter().write(input1);
}</pre>
</p>
<p>
    <b>Solution:</b>
<pre>protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    String input1 = req.getParameter("input1");
    [...]
    resp.getWriter().write(Encode.forHtml(input1));
}</pre>
</p>
<p>
The best defense against XSS is context sensitive output encoding like the example above. There are typically 4 contexts to consider: 
HTML, JavaScript, CSS (styles), and URLs. Please follow the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet,
which explains these defenses in significant detail.
</p>
<p>Note that this XSS in Servlet rule looks for similar issues, but looks for them in a different way than the existing 
'XSS: Servlet reflected cross site scripting vulnerability' and 'XSS: Servlet reflected cross site scripting vulnerability in error page' rules in FindBugs.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">WASC-8: Cross Site Scripting</a><br/>
<a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">OWASP: XSS Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)</a><br/>
<a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a><br/>
<a href="https://code.google.com/p/owasp-java-encoder/">OWASP Java Encoder</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:BAD_HEXA_CONVERSION">findsecbugs:BAD_HEXA_CONVERSION</a>
					</td>
					<td>
						<details>
							<p>When converting a byte array containing a hash signature to a human readable string, a conversion mistake can be made if 
the array is read byte by byte. The following sample illustrates the use of Integer.toHexString() which will trim any leading zeroes
from each byte of the computed hash value.
<pre>
MessageDigest md = MessageDigest.getInstance("SHA-256");
byte[] resultBytes = md.digest(password.getBytes("UTF-8"));

StringBuilder stringBuilder = new StringBuilder();
for(byte b :resultBytes) {
    stringBuilder.append( Integer.toHexString( b & 0xFF ) );
}

return stringBuilder.toString();</pre>
</p>
<p>
This mistake weakens the hash value computed since it introduces more collisions. 
For example, the hash values "0x0679" and "0x6709" would both output as "679" for the above function.
</p>

<p>
In this situation, the use of toHexString() should be replaced with String.format() as follows:
<pre>stringBuilder.append( String.format( "%02X", b ) );</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/704.html">CWE-704: Incorrect Type Conversion or Cast</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WICKET_ENDPOINT">findsecbugs:WICKET_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>This class represents a Wicket WebPage. Input is automatically read from a PageParameters instance passed to the constructor. 
The current page is mapped to the view [/package/WebPageName].html.</p>
<p>Each Wicket page in this application should be researched to make sure all inputs that are automatically 
mapped in this way are properly validated before they are used.</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://wicket.apache.org/">Apache Wicket Home Page</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_ANDROID">findsecbugs:SQL_INJECTION_ANDROID</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
</p>

<p>
    <b>Vulnerable Code:</b><br/>
    <pre>String query = "SELECT * FROM  messages WHERE uid= '"+userInput+"'" ;
Cursor cursor = this.getReadableDatabase().rawQuery(query,null);</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>String query = "SELECT * FROM  messages WHERE uid= ?" ;
Cursor cursor = this.getReadableDatabase().rawQuery(query,new String[] {userInput});</pre>
</p>
<br/>

<b>References (Android SQLite)</b><br/>
<a href="http://www.informit.com/articles/article.aspx?p=2268753&seqNum=5">InformIT.com: Practical Advice for Building Secure Android Databases in SQLite</a><br/>
<a href="https://www.packtpub.com/books/content/knowing-sql-injection-attacks-and-securing-our-android-applications-them">Packtpub.com: Knowing the SQL-injection attacks and securing our Android applications from them</a><br/>
<a href="https://books.google.ca/books?id=SXlMAQAAQBAJ&lpg=PR1&pg=PA64#v=onepage&q&f=false">Android Database Support (Enterprise Android: Programming Android Database Applications for the Enterprise)</a><br/>
<a href="https://stackoverflow.com/a/29797229/89769">Safe example of Insert, Select, Update and Delete queryies provided by Suragch</a><br/>

<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:CRLF_INJECTION_LOGS">findsecbugs:CRLF_INJECTION_LOGS</a>
					</td>
					<td>
						<details>
							<p>
    When data from an untrusted source is put into a logger and not neutralized correctly,
    an attacker could forge log entries or include malicious content.
    Inserted false entries could be used to skew statistics, distract the administrator
    or even to implicate another party in the commission of a malicious act.
    If the log file is processed automatically, the attacker can render the file unusable
    by corrupting the format of the file or injecting unexpected characters.
    An attacker may also inject code or other commands into the log file and take advantage
    of a vulnerability in the log processing utility (e.g. command injection or XSS).
</p>
<br/>
<p>
<b>Code at risk:</b><br/>
<pre>String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}
</pre>

A malicious user could send the metadata parameter with the value: <code>"Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer"</code>.
</p>

<b>Solution:</b><br/>
<p>
You can manually sanitize each parameter.
<pre>
log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");
</pre>
</p>

<p>
You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack <a href="https://logback.qos.ch/manual/layouts.html#replace">using the replace function</a>.
<pre>
&lt;pattern&gt;%-5level - %replace(%msg){'[\r\n]', ''}%n&lt;/pattern&gt;
</pre>
</p>

<br/>
<p>
    <b>References</b><br/>
    <a href="http://cwe.mitre.org/data/definitions/117.html">CWE-117: Improper Output Neutralization for Logs</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/93.html">CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')</a><br/>
    <a href="https://logback.qos.ch/manual/layouts.html#replace">CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:UNENCRYPTED_SERVER_SOCKET">findsecbugs:UNENCRYPTED_SERVER_SOCKET</a>
					</td>
					<td>
						<details>
							<p>
The communication channel used is not encrypted. The traffic could be read by an attacker intercepting the network traffic.
</p>
<p>
<b>Vulnerable Code:</b><br/>
Plain server socket (Cleartext communication):
<pre>ServerSocket soc = new ServerSocket(1234);</pre>
</p>
<p>
<b>Solution:</b><br/>
SSL Server Socket (Secure communication):
<pre>ServerSocket soc = SSLServerSocketFactory.getDefault().createServerSocket(1234);</pre>
</p>
<p>Beyond using an SSL server socket, you need to make sure your use of SSLServerSocketFactory does all the appropriate certificate validation checks to
make sure you are not subject to man-in-the-middle attacks. Please read the OWASP Transport Layer Protection Cheat Sheet for details on how
to do this correctly.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Top_10_2010-A9">OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP: Top 10 2013-A6-Sensitive Data Exposure</a><br/>
<a href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">OWASP: Transport Layer Protection Cheat Sheet</a><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/319.html">CWE-319: Cleartext Transmission of Sensitive Information</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_SPRING_JDBC">findsecbugs:SQL_INJECTION_SPRING_JDBC</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
</p>

<p>
    <b>Vulnerable Code:</b><br/>
    <pre>JdbcTemplate jdbc = new JdbcTemplate();
int count = jdbc.queryForObject("select count(*) from Users where name = '"+paramName+"'", Integer.class);
</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>JdbcTemplate jdbc = new JdbcTemplate();
int count = jdbc.queryForObject("select count(*) from Users where name = ?", Integer.class, paramName);</pre>
</p>
<br/>

<b>References (Spring JDBC)</b><br/>
<a href="http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/jdbc.html">Spring Official Documentation: Data access with JDBC</a><br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:DES_USAGE">findsecbugs:DES_USAGE</a>
					</td>
					<td>
						<details>
							<p>
DES and DESede (3DES) are not considered strong ciphers for modern applications. Currently, NIST recommends the 
usage of AES block ciphers instead of DES/3DES.
</p>
<p>
    <b>Example weak code:</b>
<pre>Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
    <b>Example solution:</b>
    <pre>Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://www.nist.gov/itl/fips/060205_des.cfm">NIST Withdraws Outdated Data Encryption Standard</a><br/>
<a href="http://cwe.mitre.org/data/definitions/326.html">CWE-326: Inadequate Encryption Strength</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_GEOLOCATION">findsecbugs:ANDROID_GEOLOCATION</a>
					</td>
					<td>
						<details>
							<p>
    It is suggested to ask the user for a confirmation about obtaining its geolocation.
</p>
<p>
    <b>Code at risk:</b><br/>
<pre>
webView.setWebChromeClient(new WebChromeClient() {
    @Override
    public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) {
        callback.invoke(origin, true, false);
    }
});
</pre>
</p>
<p>
    <b>Suggested code:</b><br/>

    Limit the sampling of geolocation and ask the user for confirmation.
<pre>
webView.setWebChromeClient(new WebChromeClient() {
    @Override
    public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) {
        callback.invoke(origin, true, false);

        //Ask the user for confirmation
    }
});
</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://www.securecoding.cert.org/confluence/display/java/DRD15-J.+Consider+privacy+concerns+when+using+Geolocation+API">CERT: DRD15-J. Consider privacy concerns when using Geolocation API</a><br/>
    <a href="http://en.wikipedia.org/wiki/W3C_Geolocation_API">Wikipedia: W3C Geolocation API</a><br/>
    <a href="http://dev.w3.org/geo/api/spec-source.html">W3C: Geolocation Specification</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION">findsecbugs:SQL_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Alternatively to prepare statements, each parameter can be escaped manually.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>
createQuery("select * from User where id = '"+inputId+"'");
</pre>
</p>
<p>
    <b>Solution:</b><br/>

    <pre>
import org.owasp.esapi.Encoder;

createQuery("select * from User where id = '"+Encoder.encodeForSQL(inputId)+"'");
</pre>
</p>
<br/>
<p>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:DESERIALIZATION_GADGET">findsecbugs:DESERIALIZATION_GADGET</a>
					</td>
					<td>
						<details>
							<p>
Deserialization gadget are class that could be used by an attacker to take advantage of a remote API using Native Serialization.
This class is either adding custom behavior to deserialization with the readObject method (Serializable) or can be called
 from a serialized object (InvocationHandler).
</p>
<p>
This detector is intended to be used mostly by researcher. The real issue is using deserialization for remote operation.
Removing gadget is an hardening practice to reduce the risk of being exploited.
</p>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/502.html">CWE-502: Deserialization of Untrusted Data</a><br/>
<a href="https://www.owasp.org/index.php/Deserialization_of_untrusted_data">Deserialization of untrusted data</a><br/>
<a href="http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8">Serialization and Deserialization </a><br/>
<a href="https://github.com/frohoff/ysoserial">A tool for generating payloads that exploit unsafe Java object deserialization</a><br/>
[1] <a href="https://gist.github.com/coekie/a27cc406fc9f3dc7a70d">Example of Denial of Service using the class java.util.HashSet</a><br/>
[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-2590">OpenJDK: Deserialization issue in ObjectInputStream.readSerialData() (CVE-2015-2590)</a><br/>
[3] <a href="https://www.rapid7.com/db/modules/exploit/multi/browser/java_calendar_deserialize">Rapid7: Sun Java Calendar Deserialization Privilege Escalation (CVE-2008-5353)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:COMMAND_INJECTION">findsecbugs:COMMAND_INJECTION</a>
					</td>
					<td>
						<details>
							<p>The highlighted API is used to execute a system command. If unfiltered input is passed to this API, it can lead to arbitrary command execution.</p>
<br/>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>import java.lang.Runtime;

Runtime r = Runtime.getRuntime();
r.exec("/bin/sh -c some_tool" + input);</pre>
</p>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Command_Injection">OWASP: Command Injection</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/78.html">CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPRING_UNVALIDATED_REDIRECT">findsecbugs:SPRING_UNVALIDATED_REDIRECT</a>
					</td>
					<td>
						<details>
							<p>
    Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied
    parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
</p>
<p>
    <b>Scenario</b><br/>
    1. A user is tricked into visiting the malicious URL: <code>http://website.com/login?redirect=http://evil.vvebsite.com/fake/login</code><br/>
    2. The user is redirected to a fake login page that looks like a site they trust. (<code>http://evil.vvebsite.com/fake/login</code>)<br/>
    3. The user enters his credentials.<br/>
    4. The evil site steals the user's credentials and redirects him to the original website.<br/>
    <br/>
    This attack is plausible because most users don't double check the URL after the redirection. Also, redirection to
    an authentication page is very common.
</p>
<p>
    <b>Vulnerable Code:</b></br/>
    <pre>@RequestMapping("/redirect")
public String redirect(@RequestParam("url") String url) {
    [...]
    return "redirect:" + url;
}</pre>
</p>
<p>
    <b>Solution/Countermeasures:</b><br/>
    <ul>
        <li>Don't accept redirection destinations from users</li>
        <li>Accept a destination key, and use it to look up the target (legal) destination</li>
        <li>Accept only relative paths</li>
        <li>White list URLs (if possible)</li>
        <li>Validate that the beginning of the URL is part of a white list</li>
    </ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse">WASC-38: URL Redirector Abuse</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards">OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards</a><br/>
<a href="https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet">OWASP: Unvalidated Redirects and Forwards Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/601.html">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:STRUTS_FORM_VALIDATION">findsecbugs:STRUTS_FORM_VALIDATION</a>
					</td>
					<td>
						<details>
							<p>
Form inputs should have minimal input validation. Preventive validation helps provide defense in depth against a variety of risks.
</p>
<p>
Validation can be introduce by implementing a <code>validate</code> method.
<pre>
public class RegistrationForm extends ValidatorForm {

    private String name;
    private String email;

    [...]

    public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
        //Validation code for name and email parameters passed in via the HttpRequest goes here
    }
}
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a><br/>
<a href="http://cwe.mitre.org/data/definitions/106.html">CWE-106: Struts: Plug-in Framework not in Use</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPRING_ENDPOINT">findsecbugs:SPRING_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>This class is a Spring Controller. All methods annotated with <code>RequestMapping</code> (as well as its shortcut annotations <code>GetMapping</code>, <code>PostMapping</code>, <code>PutMapping</code>, <code>DeleteMapping</code>, and <code>PatchMapping</code>) are reachable remotely.
This class should be analyzed to make sure that remotely exposed methods are safe to expose to potential attackers.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XXE_XMLREADER">findsecbugs:XXE_XMLREADER</a>
					</td>
					<td>
						<details>
							<!--XXE_GENERIC_START-->
<h3>Attack</h3>
<p>XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received
from an untrusted source.</p>
<p><b>Risk 1: Expose local file content (XXE: <u>X</u>ML e<u>X</u>ternal <u>E</u>ntity)</b></p>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;
&lt;!DOCTYPE foo [
   &lt;!ENTITY xxe SYSTEM &quot;file:///etc/passwd&quot; &gt; ]&gt;
&lt;foo&gt;&amp;xxe;&lt;/foo&gt;</pre>
</p>
<b>Risk 2: Denial of service (XEE: <u>X</u>ml <u>E</u>ntity <u>E</u>xpansion)</b>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;!DOCTYPE lolz [
 &lt;!ENTITY lol &quot;lol&quot;&gt;
 &lt;!ELEMENT lolz (#PCDATA)&gt;
 &lt;!ENTITY lol1 &quot;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&quot;&gt;
 &lt;!ENTITY lol2 &quot;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&quot;&gt;
 &lt;!ENTITY lol3 &quot;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&quot;&gt;
[...]
 &lt;!ENTITY lol9 &quot;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&quot;&gt;
]&gt;
&lt;lolz&gt;&amp;lol9;&lt;/lolz&gt;</pre>
</p>

<h3>Solution</h3>
<p>
In order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code.
</p>
<!--XXE_GENERIC_END-->

<p><b>Vulnerable Code:</b></p>
<p>
<pre>
XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setContentHandler(customHandler);
reader.parse(new InputSource(inputStream));</pre>
</p>
<br/>
<p>
The following snippets show two available solutions. You can set one property or both.
</p>

<p><b>Solution using "Secure processing" mode:</b></p>
<p>
This setting will protect you against Denial of Service attack and remote file access.
<pre>
XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
reader.setContentHandler(customHandler);

reader.parse(new InputSource(inputStream));</pre>
</p>

<p><b>Solution disabling DTD:</b></p>
<p>
By disabling DTD, almost all XXE attacks will be prevented.
<pre>
XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
reader.setContentHandler(customHandler);

reader.parse(new InputSource(inputStream));</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<!--XXE_GENERIC_START-->
<a href="http://cwe.mitre.org/data/definitions/611.html">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61702260">CERT: IDS10-J. Prevent XML external entity attacks</a><br/>
<a href="https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing">OWASP.org: XML External Entity (XXE) Processing</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Expansion">WS-Attacks.org: XML Entity Expansion</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_External_Entity_DOS">WS-Attacks.org: XML External Entity DOS</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Reference_Attack">WS-Attacks.org: XML Entity Reference Attack</a><br/>
<a href="http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html">Identifying Xml eXternal Entity vulnerability (XXE)</a><br/>
<!--XXE_GENERIC_END-->
<a href="http://xerces.apache.org/xerces-j/features.html">Xerces complete features list</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:FORMAT_STRING_MANIPULATION">findsecbugs:FORMAT_STRING_MANIPULATION</a>
					</td>
					<td>
						<details>
							<p>
Allowing user input to control format parameters could enable an attacker to cause exceptions to be thrown or leak information.<br/>
Attackers may be able to modify the format string argument, such that an exception is thrown. If this exception is left uncaught, it may crash the application. Alternatively, if sensitive information is used within the unused arguments, attackers may change the format string to reveal this information.<br/>
The example code below lets the user specify the decimal points to which it shows the balance. The user can in fact specify anything causing an exception to be thrown which could lead to application failure. Even more critical within this example, if an attacker can specify the user input "2f %3$s %4$.2", the format string would be "The customer: %s %s has the balance %4$.2f %3$s %4$.2". This would then lead to the sensitive accountNo to be included within the resulting string.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>Formatter formatter = new Formatter(Locale.US);
String format = "The customer: %s %s has the balance %4$." + userInput + "f";
formatter.format(format, firstName, lastName, accountNo, balance);</pre>
</p>
<p>
    <b>Solution:</b><br/>
Avoid using user controlled values in the format string argument.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/134.html">CWE-134: Use of Externally-Controlled Format String</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_WORLD_WRITABLE">findsecbugs:ANDROID_WORLD_WRITABLE</a>
					</td>
					<td>
						<details>
							<p>
    The file written in this context is using the creation mode <code>MODE_WORLD_READABLE</code>. It might not be the
    expected behavior to exposed the content being written.
</p>
<p>
    <b>Code at risk:</b><br/>
<pre>
fos = openFileOutput(filename, MODE_WORLD_READABLE);
fos.write(userInfo.getBytes());
</pre>
</p>
<br/>
<p>
    <b>Solution (using MODE_PRIVATE):</b><br/>
<pre>
fos = openFileOutput(filename, MODE_PRIVATE);
</pre>
</p>
<p>
    <b>Solution (using local SQLite Database):</b><br/>

Using a local SQLite database is probably the best solution to store structured data. Make sure the database file is not
create on external storage. See references below for implementation guidelines.
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://www.securecoding.cert.org/confluence/display/java/DRD11-J.+Ensure+that+sensitive+data+is+kept+secure">CERT: DRD11-J. Ensure that sensitive data is kept secure</a><br/>
    <a href="http://developer.android.com/training/articles/security-tips.html#InternalStorage">Android Official Doc: Security Tips</a><br/>
    <a href="http://developer.android.com/reference/android/content/Context.html#MODE_PRIVATE">Android Official Doc: Context.MODE_PRIVATE</a><br/>
    <a href="http://www.vogella.com/tutorials/AndroidSQLite/article.html#databasetutorial_database">vogella.com: Android SQLite database and content provider - Tutorial</a><br/>
    <a href="https://www.owasp.org/index.php/Mobile_Top_10_2014-M2">OWASP Mobile Top 10 2014-M2: Insecure Data Storage</a><br/>
    <a href="https://cwe.mitre.org/data/definitions/312.html">CWE-312: Cleartext Storage of Sensitive Information</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ECB_MODE">findsecbugs:ECB_MODE</a>
					</td>
					<td>
						<details>
							<p>An authentication cipher mode which provides better confidentiality of the encrypted data should be used instead of Electronic Codebook (ECB) mode, 
which does not provide good confidentiality. Specifically, ECB mode produces the same output for the same input each time. So, 
for example, if a user is sending a password, the encrypted value is the same each time. This allows an attacker to intercept 
and replay the data.</p>
<p>
To fix this, something like Galois/Counter Mode (GCM) should be used instead.
</p>
<p>
<b>Code at risk:</b>
    <pre>Cipher c = Cipher.getInstance("AES/ECB/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://en.wikipedia.org/wiki/Authenticated_encryption">Wikipedia: Authenticated encryption</a><br/>
<a href="http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html#01">NIST: Authenticated Encryption Modes</a><br/>
<a href="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29">Wikipedia: Block cipher modes of operation</a><br/>
<a href="http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf">NIST: Recommendation for Block Cipher Modes of Operation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PREDICTABLE_RANDOM">findsecbugs:PREDICTABLE_RANDOM</a>
					</td>
					<td>
						<details>
							<p>The use of a predictable random value can lead to vulnerabilities when used in certain security critical contexts. For example, when the value is used as:</p>
<ul>
<li>a CSRF token: a predictable token can lead to a CSRF attack as an attacker will know the value of the token</li>
<li>a password reset token (sent by email): a predictable password token can lead to an account takeover, since an attacker will guess the URL of the change password form</li>
<li>any other secret value</li>
</ul>
<p>
A quick fix could be to replace the use of <b>java.util.Random</b> with something stronger, such as <b>java.security.SecureRandom</b>.
</p>
<p>
<b>Vulnerable Code:</b><br/>
<pre>String generateSecretToken() {
    Random r = new Random();
    return Long.toHexString(r.nextLong());
}</pre>
</p>
<p>
<b>Solution:</b>
<pre>import org.apache.commons.codec.binary.Hex;

String generateSecretToken() {
    SecureRandom secRandom = new SecureRandom();

    byte[] result = new byte[32];
    secRandom.nextBytes(result);
    return Hex.encodeHexString(result);
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html">Cracking Random Number Generators - Part 1 (http://jazzy.id.au)</a><br/>
<a href="https://www.securecoding.cert.org/confluence/display/java/MSC02-J.+Generate+strong+random+numbers">CERT: MSC02-J. Generate strong random numbers</a><br/>
<a href="http://cwe.mitre.org/data/definitions/330.html">CWE-330: Use of Insufficiently Random Values</a><br/>
<a href="http://blog.h3xstream.com/2014/12/predicting-struts-csrf-token-cve-2014.html">Predicting Struts CSRF Token (Example of real-life vulnerability and exploitation)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:UNVALIDATED_REDIRECT">findsecbugs:UNVALIDATED_REDIRECT</a>
					</td>
					<td>
						<details>
							<p>
    Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied
    parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
</p>
<p>
    <b>Scenario</b><br/>
    1. A user is tricked into visiting the malicious URL: <code>http://website.com/login?redirect=http://evil.vvebsite.com/fake/login</code><br/>
    2. The user is redirected to a fake login page that looks like a site they trust. (<code>http://evil.vvebsite.com/fake/login</code>)<br/>
    3. The user enters his credentials.<br/>
    4. The evil site steals the user's credentials and redirects him to the original website.<br/>
    <br/>
    This attack is plausible because most users don't double check the URL after the redirection. Also, redirection to
    an authentication page is very common.
</p>
<p>
    <b>Vulnerable Code:</b></br/>
    <pre>protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
    [...]
    resp.sendRedirect(req.getParameter("redirectUrl"));
    [...]
}</pre>
</p>
<p>
    <b>Solution/Countermeasures:</b><br/>
    <ul>
        <li>Don't accept redirection destinations from users</li>
        <li>Accept a destination key, and use it to look up the target (legal) destination</li>
        <li>Accept only relative paths</li>
        <li>White list URLs (if possible)</li>
        <li>Validate that the beginning of the URL is part of a white list</li>
    </ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse">WASC-38: URL Redirector Abuse</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards">OWASP: Top 10 2013-A10: Unvalidated Redirects and Forwards</a><br/>
<a href="https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet">OWASP: Unvalidated Redirects and Forwards Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/601.html">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:JAXRS_ENDPOINT">findsecbugs:JAXRS_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>This method is part of a REST Web Service (JSR311).</p>
<p>
<b>The security of this web service should be analyzed. For example:</b>
<ul>
<li>Authentication, if enforced, should be tested.</li>
<li>Access control, if enforced, should be tested.</li>
<li>The inputs should be tracked for potential vulnerabilities.</li>
<li>The communication should ideally be over SSL.</li>
<li>If the service supports writes (e.g., via POST), its vulnerability to CSRF should be investigated.<sup>[1]</sup></li>
</ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/REST_Assessment_Cheat_Sheet">OWASP: REST Assessment Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/REST_Security_Cheat_Sheet">OWASP: REST Security Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet">OWASP: Web Service Security Cheat Sheet</a><br/>
1. <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)">OWASP: Cross-Site Request Forgery</a><br/>
<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet">OWASP: CSRF Prevention Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_TURBINE">findsecbugs:SQL_INJECTION_TURBINE</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Turbine API provide a DSL to build query with Java code.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>
List&lt;Record&gt; BasePeer.executeQuery( "select * from Customer where id=" + inputId );
</pre>
</p>
<p>
    <b>Solution (using Criteria DSL):</b><br/>

    <pre>
Criteria c = new Criteria();
c.add( CustomerPeer.ID, inputId );

List&lt;Customer&gt; customers = CustomerPeer.doSelect( c );
</pre>

    <b>Solution (using specialized method):</b><br/>

<pre>
Customer customer = CustomerPeer.retrieveByPK( new NumberKey( inputId ) );
</pre>

    <b>Solution (using OWASP Encoder):</b><br/>

    <pre>
import org.owasp.esapi.Encoder;

BasePeer.executeQuery("select * from Customer where id = '"+Encoder.encodeForSQL(inputId)+"'");
</pre>
</p>
<br/>
<p>
<b>References (Turbine)</b><br/>
<a href="https://turbine.apache.org/turbine/turbine-2.1/howto/criteria-howto.html">Turbine Documentation: Criteria Howto</a><br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:BEAN_PROPERTY_INJECTION">findsecbugs:BEAN_PROPERTY_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
An attacker can set arbitrary bean properties that can compromise system integrity. Bean population functions allow to set a bean property or a nested property. An attacker can leverage this functionality to access special bean properties like class.classLoader that will allow him to override system properties and potentially execute arbitrary code.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>MyBean bean = ...;
HashMap map = new HashMap();
Enumeration names = request.getParameterNames();
while (names.hasMoreElements()) {
    String name = (String) names.nextElement();
    map.put(name, request.getParameterValues(name));
}
BeanUtils.populate(bean, map);</pre>
</p>
<p>
    <b>Solution:</b><br/>
Avoid using user controlled values to populate Bean property names.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/15.html">CWE-15: External Control of System or Configuration Setting</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SSL_CONTEXT">findsecbugs:SSL_CONTEXT</a>
					</td>
					<td>
						<details>
							<p>
    <b>Vulnerable Code:</b><br/>
<pre>
    SSLContext.getInstance("SSL");
</pre>
</p>
<p>
<p><b>Solution:</b><br/>

Upgrade your implementation to the following, and configure https.protocols JVM option to include TLSv1.2:</p>
<pre>
    SSLContext.getInstance("TLS");
</pre>
<p>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https">Diagnosing TLS, SSL, and HTTPS</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WEAK_FILENAMEUTILS">findsecbugs:WEAK_FILENAMEUTILS</a>
					</td>
					<td>
						<details>
							<p>Some FilenameUtils' methods don't filter NULL bytes (<code>0x00</code>).</p>
<p>If a null byte is injected into a filename, if this filename is passed to the underlying OS, the file retrieved will be the
name of the file that is specified prior to the NULL byte, since at the OS level, all strings are terminated by a null byte even
though Java itself doesn't care about null bytes or treat them special. This OS behavior can be used to bypass filename validation 
that looks at the end of the filename (e.g., endswith ".log") to make sure its a safe file to access.</p>
<p>To fix this, two things are recommended:
<ul>
<li>Upgrade to Java 7 update 40 or later, or Java 8+ since  
<a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014846">NULL byte injection in filenames is fixed in those versions</a>.</li>
<li>Strongly validate any filenames provided by untrusted users to make sure they are valid (i.e., don't contain null, don't include path characters, etc.)</li>
</ul>
<p>If you know you are using a modern version of Java immune to NULL byte injection, you can probably disable this rule.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246949/Null%20Byte%20Injection">WASC-28: Null Byte Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/158.html">CWE-158: Improper Neutralization of Null Byte or NUL Character</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ESAPI_ENCRYPTOR">findsecbugs:ESAPI_ENCRYPTOR</a>
					</td>
					<td>
						<details>
							<p>
    The ESAPI has a small history of vulnerabilities within the cryptography component. Here is a quick validation list to
    make sure the Authenticated Encryption is working as expected.
</p>
<p><b>1. Library Version</b></p>
<p>
    This issue is corrected in ESAPI version 2.1.0. Versions <= 2.0.1 are vulnerable to a MAC bypass (CVE-2013-5679).<br/>
</p>
<p>
    For Maven users, the plugin <a href="http://mojo.codehaus.org/versions-maven-plugin/">versions</a> can be called using the
    following command. The effective version of ESAPI will be available in the output.<br/>
    <pre>$ mvn versions:display-dependency-updates</pre>
    <br/>Output:<br/>
    <pre>
[...]
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.slf4j:slf4j-api ................................... 1.6.4 -> 1.7.7
[INFO]   org.owasp.esapi:esapi ................................. 2.0.1 -> 2.1.0
[...]
    </pre>
</p>
<p>
    or by looking at the configuration directly.<br/>
    <pre>
&lt;dependency&gt;
    &lt;groupId&gt;org.owasp.esapi&lt;/groupId&gt;
    &lt;artifactId&gt;esapi&lt;/artifactId&gt;
    &lt;version&gt;2.1.0&lt;/version&gt;
&lt;/dependency&gt;</pre>
</p>
<p>
    For Ant users, the jar used should be <a href="http://repo1.maven.org/maven2/org/owasp/esapi/esapi/2.1.0/esapi-2.1.0.jar">esapi-2.1.0.jar</a>.
</p>
<p><b>2. Configuration:</b></p>
    <p>
    The library version 2.1.0 is still vulnerable to key size being changed in the ciphertext definition (CVE-2013-5960). Some precautions need to be taken.<br/>
    <br/>
    <div><b>The cryptographic configuration of ESAPI can also be vulnerable if any of these elements are present:</b><br/>
    <b>Insecure configuration:</b><br/>
    <pre>
Encryptor.CipherText.useMAC=false

Encryptor.EncryptionAlgorithm=AES
Encryptor.CipherTransformation=AES/CBC/PKCS5Padding

Encryptor.cipher_modes.additional_allowed=CBC</pre>
    </div>
</p>
<p>
    <div>
    <b>Secure configuration:</b><br/>
    <pre>
#Needed
Encryptor.CipherText.useMAC=true

#Needed to have a solid auth. encryption
Encryptor.EncryptionAlgorithm=AES
Encryptor.CipherTransformation=AES/GCM/NoPadding

#CBC mode should be removed to avoid padding oracle
Encryptor.cipher_modes.additional_allowed=</pre>
    </div>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/ESAPI-security-bulletin1.pdf">ESAPI Security bulletin 1 (CVE-2013-5679)</a><br/>
    <a href="http://nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5679">Vulnerability Summary for CVE-2013-5679</a><br/>
    <a href="http://www.synacktiv.com/ressources/synacktiv_owasp_esapi_hmac_bypass.pdf">Synactiv: Bypassing HMAC validation in OWASP ESAPI symmetric encryption</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/310.html">CWE-310: Cryptographic Issues</a><br/>
    <a href="http://lists.owasp.org/pipermail/esapi-dev/2015-March/002533.html">ESAPI-dev mailing list: Status of CVE-2013-5960</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_QUERY_STRING">findsecbugs:SERVLET_QUERY_STRING</a>
					</td>
					<td>
						<details>
							<p>The query string is the concatenation of the GET parameter names and values. Parameters other than those intended can
be passed in.</p>
<p>For the URL request <code>/app/servlet.htm?a=1&b=2</code>, the query string extract will be <code>a=1&b=2</code></p>
<p>Just as is true for individual parameter values retrieved via methods like <code>HttpServletRequest.getParameter()</code>, 
the value obtained from <code>HttpServletRequest.getQueryString()</code> should be considered unsafe.
You may need to validate or sanitize anything pulled from the query string before passing it to sensitive APIs. 
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_JDBC">findsecbugs:SQL_INJECTION_JDBC</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
</p>

<p>
    <b>Vulnerable Code:</b><br/>
    <pre>Connection conn = [...];
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("update COFFEES set SALES = "+nbSales+" where COF_NAME = '"+coffeeName+"'");</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>Connection conn = [...];
conn.prepareStatement("update COFFEES set SALES = ? where COF_NAME = ?");
updateSales.setInt(1, nbSales);
updateSales.setString(2, coffeeName);</pre>
</p>
<br/>

<b>References (JDBC)</b><br/>
<a href="http://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html">Oracle Documentation: The Java Tutorials &gt; Prepared Statements</a><br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT">findsecbugs:ANDROID_WEB_VIEW_JAVASCRIPT</a>
					</td>
					<td>
						<details>
							<p>
    Enabling JavaScript for the WebView means that it is now susceptible to XSS. The page render should be inspected
    for potential reflected XSS, stored XSS and DOM XSS.<br/>
<pre>
WebView myWebView = (WebView) findViewById(R.id.webView);
WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);
</pre>
</p>

<p>
    <b>Code at risk:</b><br/>
Enabling JavaScript is not a bad practice. It just means that the backend code need to be audited for potential XSS.
The XSS can also be introduce client-side with DOM XSS.
<pre>
function updateDescription(newDescription) {
    $("#userDescription").html("&lt;p&gt;"+newDescription+"&lt;/p&gt;");
}
</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://www.technotalkative.com/issue-using-setjavascriptenabled-can-introduce-xss-vulnerabilities-application-review-carefully/">Issue: Using setJavaScriptEnabled can introduce XSS vulnerabilities</a><br/>
    <a href="http://developer.android.com/guide/webapps/webview.html#UsingJavaScript">Android Official Doc: WebView</a><br/>
    <a href="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">WASC-8: Cross Site Scripting</a><br/>
    <a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">OWASP: XSS Prevention Cheat Sheet</a><br/>
    <a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:EL_INJECTION">findsecbugs:EL_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
    A expression is built with a dynamic value. The source of the value(s) should be verified to avoid
    that unfiltered values fall into this risky code evaluation.
</p>
<p><b>Code at risk:</b></p>
<p>
<pre>public void evaluateExpression(String expression) {
    FacesContext context = FacesContext.getCurrentInstance();
    ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory();
    ELContext elContext = context.getELContext();
    ValueExpression vex = expressionFactory.createValueExpression(elContext, expression, String.class);
    return (String) vex.getValue(elContext);
}</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://blog.mindedsecurity.com/2015/11/reliable-os-shell-with-el-expression.html">Minded Security: Abusing EL for executing OS commands</a><br/>
    <a href="https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html">The Java EE 6 Tutorial: Expression Language</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/95.html">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a><br/>
    <a href="https://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf">Minded Security: Expression Language Injection</a><br/>
    <a href="http://danamodio.com/appsec/research/spring-remote-code-with-expression-language-injection/">Dan Amodio's blog: Remote Code with Expression Language Injection</a><br/>
    <a href="http://blog.h3xstream.com/2014/11/remote-code-execution-by-design.html">Remote Code Execution .. by design</a>: Example of malicious payload. The samples given could be used to test sandboxing rules.<br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PATH_TRAVERSAL_IN">findsecbugs:PATH_TRAVERSAL_IN</a>
					</td>
					<td>
						<details>
							<p>A file is opened to read its content. The filename comes from an <b>input</b> parameter. 
If an unfiltered parameter is passed to this file API, files from an arbitrary filesystem location could be read.</p>
<p>This rule identifies <b>potential</b> path traversal vulnerabilities. In many cases, the constructed file path cannot be controlled
by the user. If that is the case, the reported instance is a false positive.</p>
<br/>

<p>
    <b>Vulnerable Code:</b><br/>
<pre>@GET
@Path("/images/{image}")
@Produces("images/*")
public Response getImage(@javax.ws.rs.PathParam("image") String image) {
    File file = new File("resources/images/", image); //Weak point

    if (!file.exists()) {
        return Response.status(Status.NOT_FOUND).build();
    }

    return Response.ok().entity(new FileInputStream(file)).build();
}</pre>
</p>
<br/>

<p>
    <b>Solution:</b><br/>
<pre>import org.apache.commons.io.FilenameUtils;

@GET
@Path("/images/{image}")
@Produces("images/*")
public Response getImage(@javax.ws.rs.PathParam("image") String image) {
    File file = new File("resources/images/", FilenameUtils.getName(image)); //Fix

    if (!file.exists()) {
        return Response.status(Status.NOT_FOUND).build();
    }

    return Response.ok().entity(new FileInputStream(file)).build();
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC: Path Traversal</a><br/>
<a href="https://www.owasp.org/index.php/Path_Traversal">OWASP: Path Traversal</a><br/>
<a href="http://capec.mitre.org/data/definitions/126.html">CAPEC-126: Path Traversal</a><br/>
<a href="http://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:MALICIOUS_XSLT">findsecbugs:MALICIOUS_XSLT</a>
					</td>
					<td>
						<details>
							<p>
    "XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents".<sup>[1]</sup><br/>
    It is possible to attach malicious behavior to those stylesheets. Therefore, if an attacker can control the content or the source of the
    stylesheet, he might be able to trigger remote code execution.<sup>[2]</sup>
</p>
<p>
<b>Code at risk:</b><br/>
<pre>
Source xslt = new StreamSource(new FileInputStream(inputUserFile)); //Dangerous source to validate

Transformer transformer = TransformerFactory.newInstance().newTransformer(xslt);

Source text = new StreamSource(new FileInputStream("/data_2_process.xml"));
transformer.transform(text, new StreamResult(...));
</pre>
</p>
<p>
<b>Solution:</b><br/>
<p>
The solution would be to make sure the stylesheet is loaded from a safe sources and make sure that vulnerabilities such as
Path traversal <sup>[3][4]</sup> are not possible.
</p>
<p>
<b>References</b><br/>
[1] <a href="https://en.wikipedia.org/wiki/XSLT">Wikipedia: XSLT (Extensible Stylesheet Language Transformations)</a><br/>
<a href="https://prezi.com/y_fuybfudgnd/offensive-xslt/">Offensive XSLT</a> by Nicolas Gregoire<br/>
[2] <a href="http://www.agarri.fr/kom/archives/2012/07/02/from_xslt_code_execution_to_meterpreter_shells/index.html">From XSLT code execution to Meterpreter shells</a> by Nicolas Gregoire<br/>
<a href="http://xhe.myxwiki.org/xwiki/bin/view/Main/">XSLT Hacking Encyclopedia</a> by Nicolas Gregoire<br/>
<a href="http://www.acunetix.com/blog/articles/the-hidden-dangers-of-xsltprocessor-remote-xsl-injection/">Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection</a><br/>
<a href="https://www.w3.org/TR/xslt">w3.org XSL Transformations (XSLT) Version 1.0</a> : w3c specification<br/>
[3] <a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC: Path Traversal</a><br/>
[4] <a href="https://www.owasp.org/index.php/Path_Traversal">OWASP: Path Traversal</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:STRUTS2_ENDPOINT">findsecbugs:STRUTS2_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>In Struts 2, the endpoints are Plain Old Java Objects (POJOs) which means no Interface/Class needs to be implemented/extended.</p>
<p>When a request is routed to its controller (like the selected class), the supplied HTTP parameters are automatically mapped to setters for
the class. Therefore, all setters of this class should be considered as untrusted input even if the form doesn't include those values. 
An attacker can simply provide additional values in the request, and they will be set in the object anyway, as long as that object has
such a setter. The use of these parameters should be reviewed to make sure they are used safely.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_HEADER_USER_AGENT">findsecbugs:SERVLET_HEADER_USER_AGENT</a>
					</td>
					<td>
						<details>
							<p>The header "User-Agent" can easily be spoofed by the client. Adopting different behaviors based on the User-Agent (for
crawler UA) is not recommended.</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/807.html">CWE-807: Untrusted Inputs in a Security Decision</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:STRUTS_FILE_DISCLOSURE">findsecbugs:STRUTS_FILE_DISCLOSURE</a>
					</td>
					<td>
						<details>
							<p>
Constructing a server-side redirect path with user input could allow an attacker to download application binaries (including application classes or jar files) or view arbitrary files within protected directories.<br/>
An attacker may be able to forge a request parameter to match sensitive file locations. For example, requesting "http://example.com/?returnURL=WEB-INF/applicationContext.xml" would display the application's applicationContext.xml file. The attacker would be able to locate and download the applicationContext.xml referenced in the other configuration files, and even class files or jar files, obtaining sensitive information and launching other types of attacks.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>... 
String returnURL = request.getParameter("returnURL"); 
Return new ActionForward(returnURL); 
...</pre>
</p>
<p>
    <b>Solution:</b><br/>
Avoid constructing server-side redirects using user controlled input.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/552.html">CWE-552: Files or Directories Accessible to External Parties</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XXE_SAXPARSER">findsecbugs:XXE_SAXPARSER</a>
					</td>
					<td>
						<details>
							<!--XXE_GENERIC_START-->
<h3>Attack</h3>
<p>XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received
from an untrusted source.</p>
<p><b>Risk 1: Expose local file content (XXE: <u>X</u>ML e<u>X</u>ternal <u>E</u>ntity)</b></p>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;
&lt;!DOCTYPE foo [
   &lt;!ENTITY xxe SYSTEM &quot;file:///etc/passwd&quot; &gt; ]&gt;
&lt;foo&gt;&amp;xxe;&lt;/foo&gt;</pre>
</p>
<b>Risk 2: Denial of service (XEE: <u>X</u>ml <u>E</u>ntity <u>E</u>xpansion)</b>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;!DOCTYPE lolz [
 &lt;!ENTITY lol &quot;lol&quot;&gt;
 &lt;!ELEMENT lolz (#PCDATA)&gt;
 &lt;!ENTITY lol1 &quot;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&quot;&gt;
 &lt;!ENTITY lol2 &quot;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&quot;&gt;
 &lt;!ENTITY lol3 &quot;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&quot;&gt;
[...]
 &lt;!ENTITY lol9 &quot;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&quot;&gt;
]&gt;
&lt;lolz&gt;&amp;lol9;&lt;/lolz&gt;</pre>
</p>

<h3>Solution</h3>
<p>
In order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code.
</p>
<!--XXE_GENERIC_END-->

<p><b>Vulnerable Code:</b></p>
<p>
<pre>
SAXParser parser = SAXParserFactory.newInstance().newSAXParser();

parser.parse(inputStream, customHandler);</pre>
</p>
<br/>
<p>
The following snippets show two available solutions. You can set one feature or both.
</p>

<p><b>Solution using "Secure processing" mode:</b></p>
<p>
This setting will protect you against Denial of Service attack and remote file access.
<pre>
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
SAXParser parser = spf.newSAXParser();

parser.parse(inputStream, customHandler);</pre>
</p>

<p><b>Solution disabling DTD:</b></p>
<p>
By disabling DTD, almost all XXE attacks will be prevented.
<pre>
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
SAXParser parser = spf.newSAXParser();

parser.parse(inputStream, customHandler);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<!--XXE_GENERIC_START-->
<a href="http://cwe.mitre.org/data/definitions/611.html">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61702260">CERT: IDS10-J. Prevent XML external entity attacks</a><br/>
<a href="https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing">OWASP.org: XML External Entity (XXE) Processing</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Expansion">WS-Attacks.org: XML Entity Expansion</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_External_Entity_DOS">WS-Attacks.org: XML External Entity DOS</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Reference_Attack">WS-Attacks.org: XML Entity Reference Attack</a><br/>
<a href="http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html">Identifying Xml eXternal Entity vulnerability (XXE)</a><br/>
<!--XXE_GENERIC_END-->
<a href="http://xerces.apache.org/xerces-j/features.html">Xerces complete features list</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_HIBERNATE">findsecbugs:SQL_INJECTION_HIBERNATE</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
Alternatively to prepare statements, Hibernate Criteria can be used.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>
Session session = sessionFactory.openSession();
Query q = session.createQuery("select t from UserEntity t where id = " + input);
q.execute();</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>
Session session = sessionFactory.openSession();
Query q = session.createQuery("select t from UserEntity t where id = :userId");
q.setString("userId",input);
q.execute();</pre>
</p>
<p>
    <b>Solution for dynamic queries (with Hibernate Criteria):</b><br/>
    <pre>
Session session = sessionFactory.openSession();
Query q = session.createCriteria(UserEntity.class)
    .add( Restrictions.like("id", input) )
    .list();
q.execute();</pre>
</p>
<br/>
<p>
<b>References (Hibernate)</b><br/>
<a href="https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/querycriteria.html">Hibernate Documentation: Query Criteria</a><br/>
<a href="https://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/Query.html">Hibernate Javadoc: Query Object</a><br/>
<a href="http://blog.h3xstream.com/2014/02/hql-for-pentesters.html">HQL for pentesters</a>: Guideline to test if the suspected code is exploitable.<br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XXE_XMLSTREAMREADER">findsecbugs:XXE_XMLSTREAMREADER</a>
					</td>
					<td>
						<details>
							<!--XXE_GENERIC_START-->
<h3>Attack</h3>
<p>XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received
from an untrusted source.</p>
<p><b>Risk 1: Expose local file content (XXE: <u>X</u>ML e<u>X</u>ternal <u>E</u>ntity)</b></p>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;
&lt;!DOCTYPE foo [
   &lt;!ENTITY xxe SYSTEM &quot;file:///etc/passwd&quot; &gt; ]&gt;
&lt;foo&gt;&amp;xxe;&lt;/foo&gt;</pre>
</p>
<b>Risk 2: Denial of service (XEE: <u>X</u>ml <u>E</u>ntity <u>E</u>xpansion)</b>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;!DOCTYPE lolz [
 &lt;!ENTITY lol &quot;lol&quot;&gt;
 &lt;!ELEMENT lolz (#PCDATA)&gt;
 &lt;!ENTITY lol1 &quot;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&quot;&gt;
 &lt;!ENTITY lol2 &quot;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&quot;&gt;
 &lt;!ENTITY lol3 &quot;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&quot;&gt;
[...]
 &lt;!ENTITY lol9 &quot;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&quot;&gt;
]&gt;
&lt;lolz&gt;&amp;lol9;&lt;/lolz&gt;</pre>
</p>

<h3>Solution</h3>
<p>
In order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code.
</p>
<!--XXE_GENERIC_END-->

<p><b>Vulnerable Code:</b></p>
<p>
<pre>public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}</pre>
</p>
<br/>
<p>
The following snippets show two available solutions. You can set one property or both.
</p>

<p><b>Solution disabling External Entities:</b></p>
<p>
<pre>public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}</pre>
</p>

<p><b>Solution disabling DTD:</b></p>
<p>
<pre>public void parseXML(InputStream input) throws XMLStreamException {

    XMLInputFactory factory = XMLInputFactory.newFactory();
    factory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
    XMLStreamReader reader = factory.createXMLStreamReader(input);
    [...]
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<!--XXE_GENERIC_START-->
<a href="http://cwe.mitre.org/data/definitions/611.html">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61702260">CERT: IDS10-J. Prevent XML external entity attacks</a><br/>
<a href="https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing">OWASP.org: XML External Entity (XXE) Processing</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Expansion">WS-Attacks.org: XML Entity Expansion</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_External_Entity_DOS">WS-Attacks.org: XML External Entity DOS</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Reference_Attack">WS-Attacks.org: XML Entity Reference Attack</a><br/>
<a href="http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html">Identifying Xml eXternal Entity vulnerability (XXE)</a><br/>
<!--XXE_GENERIC_END-->
<a href="http://openjdk.java.net/jeps/185">JEP 185: Restrict Fetching of External XML Resources</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_CONTENT_TYPE">findsecbugs:SERVLET_CONTENT_TYPE</a>
					</td>
					<td>
						<details>
							<p>
The HTTP header Content-Type can be controlled by the client. As such, its value should not be used in any security critical decisions.
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/807.html">CWE-807: Untrusted Inputs in a Security Decision</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_SERVER_NAME">findsecbugs:SERVLET_SERVER_NAME</a>
					</td>
					<td>
						<details>
							<p>The hostname header can be controlled by the client. As such, its value should not be used in any security critical decisions. 
Both <code>ServletRequest.getServerName()</code> and <code>HttpServletRequest.getHeader("Host")</code> have the same 
behavior which is to extract the <code>Host</code> header.</p>
<pre>
GET /testpage HTTP/1.1
Host: www.example.com
[...]</pre>
<p>
The web container serving your application may redirect requests to your application by default. This would allow
a malicious user to place any value in the Host header. It is recommended that you do not trust this value in any security
decisions you make with respect to a request.
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/807.html">CWE-807: Untrusted Inputs in a Security Decision</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:DEFAULT_HTTP_CLIENT">findsecbugs:DEFAULT_HTTP_CLIENT</a>
					</td>
					<td>
						<details>
							<p>
    <b>Vulnerable Code:</b><br/>
<pre>
    HttpClient client = new DefaultHttpClient();
</pre>
</p>
<p>
<p><b>Solution:</b><br/>

Upgrade your implementation to use one of the recommended constructs and configure https.protocols JVM option to include TLSv1.2:</p>

<p>
<ul>
  <li>Use <a href="http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/SystemDefaultHttpClient.html">SystemDefaultHttpClient</a> instead</li>
<p>
    <b>Sample Code:</b><br/>
<pre>
    HttpClient client = new SystemDefaultHttpClient();
</pre>
</p>
  <li>Create an HttpClient based on SSLSocketFactory - get an SSLScoketFactory instance with <a href="https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/SSLSocketFactory.html#getSystemSocketFactory()">getSystemSocketFactory()</a> and use this instance for HttpClient creation</li>
  <li>Create an HttpClient based on SSLConnectionSocketFactory - get an instance with <a href="https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFactory.html#getSystemSocketFactory()">getSystemSocketFactory()</a> and use this instance for HttpClient creation</li>
  <li>Use HttpClientBuilder - call <a href="http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#useSystemProperties()">useSystemProperties()</a> before calling build()</li>
<p>
    <b>Sample Code:</b><br/>
<pre>
    HttpClient client = HttpClientBuilder.create().useSystemProperties().build();
</pre>
</p>
  <li>HttpClients - call <a href="https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClients.html#createSystem()">createSystem()</a> to create an instance</li>
<p>
    <b>Sample Code:</b><br/>
<pre>
    HttpClient client = HttpClients.createSystem();
</pre>
</p>
</ul>
</p>
<br/>

<p>
<b>References</b><br/>
<a href="https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https">Diagnosing TLS, SSL, and HTTPS</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HAZELCAST_SYMMETRIC_ENCRYPTION">findsecbugs:HAZELCAST_SYMMETRIC_ENCRYPTION</a>
					</td>
					<td>
						<details>
							<p>The network communications for Hazelcast is configured to use a symmetric cipher (probably DES or blowfish).</p>
<p>Those ciphers alone do not provide integrity or secure authentication. The use of asymmetric encryption is preferred.</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a><br/>
<a href="http://docs.hazelcast.org/docs/3.5/manual/html/encryption.html">Hazelcast Documentation: Encryption</a><br/>
<a href="http://cwe.mitre.org/data/definitions/326.html">CWE-326: Inadequate Encryption Strength</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:JAXWS_ENDPOINT">findsecbugs:JAXWS_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>This method is part of a SOAP Web Service (JSR224).</p>
<p>
<b>The security of this web service should be analyzed. For example:</b>
<ul>
<li>Authentication, if enforced, should be tested.</li>
<li>Access control, if enforced, should be tested.</li>
<li>The inputs should be tracked for potential vulnerabilities.</li>
<li>The communication should ideally be over SSL.</li>
</ul>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet">OWASP: Web Service Security Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:CIPHER_INTEGRITY">findsecbugs:CIPHER_INTEGRITY</a>
					</td>
					<td>
						<details>
							<p>
    The ciphertext produced is susceptible to alteration by an adversary. This mean that the cipher provides no way to detect that the 
    data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection.
</p>
<p>
    The solution is to used a cipher that includes a Hash based Message Authentication Code (HMAC) to sign the data. Combining a HMAC function to the 
    existing cipher is prone to error <sup><a href="http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/">[1]</a></sup>. Specifically,
    it is always recommended that you be able to verify the HMAC first, and only if the data is unmodified, do you then perform any cryptographic
    functions on the data.
</p>
<p>The following modes are vulnerable because they don't provide a HMAC:<br/>
    - CBC<br/>
    - OFB<br/>
    - CTR<br/>
    - ECB<br/><br/>
    The following snippets code are some examples of vulnerable code.<br/><br/>
    <b>Code at risk:</b><br/>
    <i>AES in CBC mode</i><br/>

    <pre>Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
    <br/>
    <i>Triple DES with ECB mode</i><br/>

<pre>Cipher c = Cipher.getInstance("DESede/ECB/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
In the example solution above, the GCM mode introduces an HMAC into the resulting encrypted data, providing integrity of the result.
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://en.wikipedia.org/wiki/Authenticated_encryption">Wikipedia: Authenticated encryption</a><br/>
    <a href="http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html#01">NIST: Authenticated Encryption Modes</a><br/>
    <a href="http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/">Moxie Marlinspike's blog: The Cryptographic Doom Principle</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/353.html">CWE-353: Missing Support for Integrity Check</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:INSECURE_SMTP_SSL">findsecbugs:INSECURE_SMTP_SSL</a>
					</td>
					<td>
						<details>
							<p>
Server identity verification is disabled when making SSL connections. Some email libraries that enable SSL connections do not verify the server certificate by default. This is equivalent to trusting all certificates. When trying to connect to the server, this application would readily accept a certificate issued to "hackedserver.com". The application would now potentially leak sensitive user information on a broken SSL connection to the hacked server.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>...
Email email = new SimpleEmail();
email.setHostName("smtp.servermail.com");
email.setSmtpPort(465);
email.setAuthenticator(new DefaultAuthenticator(username, password));
email.setSSLOnConnect(true);
email.setFrom("user@gmail.com");
email.setSubject("TestMail");
email.setMsg("This is a test mail ... :-)");
email.addTo("foo@bar.com");
email.send();
...</pre>
</p>
<p>
    <b>Solution:</b><br/>
Please add the following check to verify the server cerfiticate:
<pre>email.setSSLCheckServerIdentity(true);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/297.html">CWE-297: Improper Validation of Certificate with Host Mismatch</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_PARAMETER">findsecbugs:SERVLET_PARAMETER</a>
					</td>
					<td>
						<details>
							<p>The Servlet can read GET and POST parameters from various methods. The value obtained should be considered unsafe.
You may need to validate or sanitize those values before passing them to sensitive APIs such as:</p>
<ul>
<li>SQL query (May lead to SQL injection)</li>
<li>File opening (May lead to path traversal)</li>
<li>Command execution (Potential Command injection)</li>
<li>HTML construction (Potential XSS)</li>
<li>etc...</li>
</ul>

<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:TEMPLATE_INJECTION_VELOCITY">findsecbugs:TEMPLATE_INJECTION_VELOCITY</a>
					</td>
					<td>
						<details>
							<p>
Velocity template engine is powerful. It is possible to add logic including condition statements, loops and external calls.
It is not design to be sandbox to templating operations. A malicious user in control of a template can run malicious code
on the server-side. Velocity templates should be seen as scripts.
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>[...]

Velocity.evaluate(context, swOut, "test", userInput);</pre>
</p>
<p>
    <b>Solution:</b>
<br/>
Avoid letting end users manipulate templates with Velocity. If you need to expose template editing to your users,
prefer logic-less template engines such as Handlebars or Moustache (See references).
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://blog.portswigger.net/2015/08/server-side-template-injection.html">PortSwigger: Server-Side Template Injection </a><br/>
<a href="https://jknack.github.io/handlebars.java/">Handlebars.java</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XXE_DOCUMENT">findsecbugs:XXE_DOCUMENT</a>
					</td>
					<td>
						<details>
							<!--XXE_GENERIC_START-->
<h3>Attack</h3>
<p>XML External Entity (XXE) attacks can occur when an XML parser supports XML entities while processing XML received
from an untrusted source.</p>
<p><b>Risk 1: Expose local file content (XXE: <u>X</u>ML e<u>X</u>ternal <u>E</u>ntity)</b></p>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;
&lt;!DOCTYPE foo [
   &lt;!ENTITY xxe SYSTEM &quot;file:///etc/passwd&quot; &gt; ]&gt;
&lt;foo&gt;&amp;xxe;&lt;/foo&gt;</pre>
</p>
<b>Risk 2: Denial of service (XEE: <u>X</u>ml <u>E</u>ntity <u>E</u>xpansion)</b>
<p>
<pre>
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;!DOCTYPE lolz [
 &lt;!ENTITY lol &quot;lol&quot;&gt;
 &lt;!ELEMENT lolz (#PCDATA)&gt;
 &lt;!ENTITY lol1 &quot;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&amp;lol;&quot;&gt;
 &lt;!ENTITY lol2 &quot;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&amp;lol1;&quot;&gt;
 &lt;!ENTITY lol3 &quot;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&amp;lol2;&quot;&gt;
[...]
 &lt;!ENTITY lol9 &quot;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&amp;lol8;&quot;&gt;
]&gt;
&lt;lolz&gt;&amp;lol9;&lt;/lolz&gt;</pre>
</p>

<h3>Solution</h3>
<p>
In order to avoid exposing dangerous feature of the XML parser, you can do the following change to the code.
</p>
<!--XXE_GENERIC_END-->

<p><b>Vulnerable Code:</b></p>
<p>
<pre>
DocumentBuilder db = DocumentBuilderFactory.newInstance().newDocumentBuilder();

Document doc = db.parse(input);</pre>
</p>
<br/>
<p>
The following snippets show two available solutions. You can set one feature or both.
</p>

<p><b>Solution using "Secure processing" mode:</b></p>
<p>
This setting will protect you against Denial of Service attack and remote file access.
<pre>
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
DocumentBuilder db = dbf.newDocumentBuilder();

Document doc = db.parse(input);</pre>
</p>

<p><b>Solution disabling DTD:</b></p>
<p>
By disabling DTD, almost all XXE attacks will be prevented.
<pre>
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
DocumentBuilder db = dbf.newDocumentBuilder();

Document doc = db.parse(input);</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<!--XXE_GENERIC_START-->
<a href="http://cwe.mitre.org/data/definitions/611.html">CWE-611: Improper Restriction of XML External Entity Reference ('XXE')</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61702260">CERT: IDS10-J. Prevent XML external entity attacks</a><br/>
<a href="https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing">OWASP.org: XML External Entity (XXE) Processing</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Expansion">WS-Attacks.org: XML Entity Expansion</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_External_Entity_DOS">WS-Attacks.org: XML External Entity DOS</a><br/>
<a href="http://www.ws-attacks.org/index.php/XML_Entity_Reference_Attack">WS-Attacks.org: XML Entity Reference Attack</a><br/>
<a href="http://blog.h3xstream.com/2014/06/identifying-xml-external-entity.html">Identifying Xml eXternal Entity vulnerability (XXE)</a><br/>
<!--XXE_GENERIC_END-->
<a href="http://xerces.apache.org/xerces2-j/features.html">Xerces2 complete features list</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:PADDING_ORACLE">findsecbugs:PADDING_ORACLE</a>
					</td>
					<td>
						<details>
							<p>
    This specific mode of CBC with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the
    message if the system exposed the difference between plaintext with invalid padding or valid padding. The distinction between
    valid and invalid padding is usually revealed through distinct error messages being returned for each condition.
</p>
<p>
    <b>Code at risk:</b>
    <pre>Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://www.infobytesec.com/down/paddingoracle_openjam.pdf">Padding Oracles for the masses (by Matias Soler)</a><br/>
    <a href="http://en.wikipedia.org/wiki/Authenticated_encryption">Wikipedia: Authenticated encryption</a><br/>
    <a href="http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html#01">NIST: Authenticated Encryption Modes</a><br/>
    <a href="http://capec.mitre.org/data/definitions/463.html">CAPEC: Padding Oracle Crypto Attack</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/696.html">CWE-696: Incorrect Behavior Order</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_BROADCAST">findsecbugs:ANDROID_BROADCAST</a>
					</td>
					<td>
						<details>
							<p>
    Broadcast intents can be listen by any application with the appropriate permission. It is suggested to avoid transmitting
    sensitive information when possible.
</p>
<p>
    <b>Code at risk:</b><br/>
<pre>
Intent i = new Intent();
i.setAction("com.insecure.action.UserConnected");
i.putExtra("username", user);
i.putExtra("email", email);
i.putExtra("session", newSessionId);

this.sendBroadcast(v1);
</pre>
</p>
<br/>
<p>
    <b>Solution (if possible):</b><br/>
<pre>
Intent i = new Intent();
i.setAction("com.secure.action.UserConnected");

sendBroadcast(v1);
</pre>
</p>
<br/>
<p>
    <b>Configuration (receiver)<sup>[1] Source: StackOverflow</sup>:</b><br/>
<pre>
&lt;manifest ...&gt;

    &lt;!-- Permission declaration --&gt;
    &lt;permission android:name="my.app.PERMISSION" /&gt;

    &lt;receiver
        android:name="my.app.BroadcastReceiver"
        android:permission="my.app.PERMISSION"&gt; &lt;!-- Permission enforcement --&gt;
        &lt;intent-filter>
            &lt;action android:name="com.secure.action.UserConnected" /&gt;
        &lt;/intent-filter&gt;
    &lt;/receiver&gt;

    ...
&lt;/manifest>
</pre>
</p>
<p>
    <b>Configuration (sender)<sup>[1] Source: StackOverflow</sup>:</b><br/>
<pre>
&lt;manifest&gt;
    &lt;!-- We declare we own the permission to send broadcast to the above receiver --&gt;
    &lt;uses-permission android:name="my.app.PERMISSION"/&gt;

    &lt;!-- With the following configuration, both the sender and the receiver apps need to be signed by the same developer certificate. --&gt;
    &lt;permission android:name="my.app.PERMISSION" android:protectionLevel="signature"/&gt;
&lt;/manifest&gt;
</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://www.securecoding.cert.org/confluence/display/java/DRD03-J.+Do+not+broadcast+sensitive+information+using+an+implicit+intent">CERT: DRD03-J. Do not broadcast sensitive information using an implicit intent</a><br/>
    <a href="http://developer.android.com/reference/android/content/BroadcastReceiver.html#Security">Android Official Doc: BroadcastReceiver (Security)</a><br/>
    <a href="http://developer.android.com/guide/topics/manifest/receiver-element.html">Android Official Doc: Receiver configuration (see <code>android:permission</code>)</a><br/>
    <sup>[1]</sup> <a href="http://stackoverflow.com/a/21513368/89769">StackOverflow: How to set permissions in broadcast sender and receiver in android</a><br/>
    <a href="https://cwe.mitre.org/data/definitions/925.html">CWE-925: Improper Verification of Intent by Broadcast Receiver</a><br/>
    <a href="https://cwe.mitre.org/data/definitions/927.html">CWE-927: Use of Implicit Intent for Sensitive Communication</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:AWS_QUERY_INJECTION">findsecbugs:AWS_QUERY_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
Constructing SimpleDB queries containing user input can allow an attacker to view unauthorized records.<br/>
The following example dynamically constructs and executes a SimpleDB select() query allowing the user to specify the productCategory. The attacker can modify the query, bypass the required authentication for customerID and view records matching any customer.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
String productCategory = request.getParameter("productCategory");
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
            + productCategory + "' and customerID = '"
            + customerID + "' order by '"
            + sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
</pre>
</p>
<p>
    <b>Solution:</b><br/>
This issue is analogical to SQL Injection. Sanitize user input before using it in a SimpleDB query.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://cwe.mitre.org/data/definitions/943.html">CWE-943: Improper Neutralization of Special Elements in Data Query Logic</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:STRUTS1_ENDPOINT">findsecbugs:STRUTS1_ENDPOINT</a>
					</td>
					<td>
						<details>
							<p>This class is a Struts 1 Action.</p>
<p>Once a request is routed to this controller, a Form object will automatically be instantiated that contains the HTTP parameters. 
The use of these parameters should be reviewed to make sure they are used safely.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:EXTERNAL_CONFIG_CONTROL">findsecbugs:EXTERNAL_CONFIG_CONTROL</a>
					</td>
					<td>
						<details>
							<p>
    Allowing external control of system settings can disrupt service or cause an application
    to behave in unexpected, and potentially malicious ways. 
    An attacker could cause an error by providing a nonexistent catalog name
    or connect to an unauthorized portion of the database.
</p>
<br/>
<p>
<b>Code at risk:</b><br/>
<pre>conn.setCatalog(request.getParameter("catalog"));</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://cwe.mitre.org/data/definitions/15.html">CWE-15: External Control of System or Configuration Setting</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:RSA_KEY_SIZE">findsecbugs:RSA_KEY_SIZE</a>
					</td>
					<td>
						<details>
							<p>
    The NIST recommends the use of <u>2048 bits and higher</u> keys for the RSA algorithm.
</p>
<blockquote>
    "Digital Signature Verification | RSA: 1024 &le; len(n) &lt; 2048 | Legacy-use"<br/>
    "Digital Signature Verification | RSA: len(n) &ge; 2048 | Acceptable"<br/>
    - <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7</a>
</blockquote>

<p><b>Vulnerable Code:</b><br/>
<pre>
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(512);
</pre>
</p>

<p><b>Solution:</b><br/>
The KeyPairGenerator creation should be as follows with at least 2048 bit key size.<br/>
<pre>
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(2048);
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://csrc.nist.gov/groups/ST/toolkit/key_management.html">NIST: Latest publication on key management</a><br/>
<a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">NIST: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths p.7</a><br/>
<a href="http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/how-large-a-key-should-be-used.htm">RSA Laboratories: 3.1.5 How large a key should be used in the RSA cryptosystem?</a><br/>
<a href="http://en.wikipedia.org/wiki/Key_size#Asymmetric%5Falgorithm%5Fkey%5Flengths">Wikipedia: Asymmetric algorithm key lengths</a><br/>
<a href="http://cwe.mitre.org/data/definitions/326.html">CWE-326: Inadequate Encryption Strength</a><br/>
<a href="http://www.keylength.com/en/compare/">Keylength.com (BlueKrypt): Aggregate key length recommendations.</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:OGNL_INJECTION">findsecbugs:OGNL_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
    A expression is built with a dynamic value. The source of the value(s) should be verified to avoid
    that unfiltered values fall into this risky code evaluation.
</p>
<p><b>Code at risk:</b></p>
<p>
<pre>
public void getUserProperty(String property) {
  [...]
  //The first argument is the dynamic expression.
  return ognlUtil.getValue("user."+property, ctx, root, String.class);
}
</pre>
</p>
<p><b>Solution:</b></p>
<p>
In general, method evaluating OGNL expression should not received user input. It is intented to be used in static configurations and JSP.
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="https://community.saas.hpe.com/t5/Security-Research/Struts-2-OGNL-Expression-Injections/ba-p/288881">HP Enterprise: Struts 2 OGNL Expression Injections by Alvaro Mu&Atilde;&plusmn;oz</a><br/>
    <a href="https://blog.gdssecurity.com/labs/2017/3/27/an-analysis-of-cve-2017-5638.html">Gotham Digital Science: An Analysis Of CVE-2017-5638</a><br/>
    <a href="http://struts.apache.org/docs/s2-016.html">Apache Struts2: Vulnerability S2-016</a><br/>
    <a href="https://struts.apache.org/docs/ognl.html">Apache Struts 2 Documentation: OGNL</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:COOKIE_USAGE">findsecbugs:COOKIE_USAGE</a>
					</td>
					<td>
						<details>
							<p>The information stored in a custom cookie should not be sensitive or related to the session. In most cases, sensitive data should only be stored in session
and referenced by the user's session cookie. See HttpSession (HttpServletRequest.getSession())</p>
<p>Custom cookies can be used for information that needs to live longer than and is independent of a specific session.</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://cwe.mitre.org/data/definitions/315.html">CWE-315: Cleartext Storage of Sensitive Information in a Cookie</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:TRUST_BOUNDARY_VIOLATION">findsecbugs:TRUST_BOUNDARY_VIOLATION</a>
					</td>
					<td>
						<details>
							<p>
    "A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted.
    On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data
    to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a
    program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the
    same data structure, it becomes easier for programmers to mistakenly trust unvalidated data." <sup>[1]</sup>
</p>

<p>
<b>Code at risk:</b><br/>
<pre>
public void doSomething(HttpServletRequest req, String activateProperty) {
    //..

    req.getSession().setAttribute(activateProperty,"true");

}
</pre>
<br/>
<pre>
public void loginEvent(HttpServletRequest req, String userSubmitted) {
    //..

    req.getSession().setAttribute("user",userSubmitted);
}
</pre>
</p>

<p>
<b>Solution:</b><br/>
<p>
The solution would be to add validation prior setting a new session attribute. When possible, prefer data from
safe location rather than using direct user input.
</p>
<br/>
<p>
<b>References</b><br/>
[1] <a href="https://cwe.mitre.org/data/definitions/501.html">CWE-501: Trust Boundary Violation</a><br/>
<a href="https://www.owasp.org/index.php/Trust_Boundary_Violation">OWASP : Trust Boundary Violation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:WEAK_HOSTNAME_VERIFIER">findsecbugs:WEAK_HOSTNAME_VERIFIER</a>
					</td>
					<td>
						<details>
							<p>A <code>HostnameVerifier</code> that accept any host are often use because of certificate reuse on many hosts.
As a consequence, this is vulnerable to
<a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">Man-in-the-middle attacks</a>
since the client will trust any certificate.
</p>
<p>
A TrustManager allowing specific certificates (based on a truststore for example) should be built.
Wildcard certificates should be created for reused on multiples subdomains.
Detailed information for a proper implementation is available at:
<a href="http://stackoverflow.com/a/6378872/89769">[1]</a>
<a href="http://stackoverflow.com/a/5493452/89769">[2]</a>
</p>
<br/>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>public class AllHosts implements HostnameVerifier {
    public boolean verify(final String hostname, final SSLSession session) {
        return true;
    }
}</pre>
</p>
<br/>
<p>
    <b>Solution (TrustMangager based on a keystore):</b><br/>
<pre>KeyStore ks = //Load keystore containing the certificates trusted

SSLContext sc = SSLContext.getInstance("TLS");

TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);

sc.init(kmf.getKeyManagers(), tmf.getTrustManagers(),null);
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/295.html">CWE-295: Improper Certificate Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:ANDROID_EXTERNAL_FILE_ACCESS">findsecbugs:ANDROID_EXTERNAL_FILE_ACCESS</a>
					</td>
					<td>
						<details>
							<p>
    The application write data to external storage (potentially SD card). There are multiple security implication to this
    action. First, file store on SD card will be accessible to the application having the
    <a href="http://developer.android.com/reference/android/Manifest.permission.html#READ_EXTERNAL_STORAGE"><code>READ_EXTERNAL_STORAGE</code></a> permission.
    Also, if the data persisted contains confidential information about the user, encryption would be needed.
</p>
<p>
    <b>Code at risk:</b><br/>
<pre>
file file = new File(getExternalFilesDir(TARGET_TYPE), filename);
fos = new FileOutputStream(file);
fos.write(confidentialData.getBytes());
fos.flush();
</pre>
</p>
<p>
    <b>Better alternative:</b><br/>
<pre>
fos = openFileOutput(filename, Context.MODE_PRIVATE);
fos.write(string.getBytes());
</pre>
</p>
<br/>
<p>
    <b>References</b><br/>
    <a href="http://developer.android.com/training/articles/security-tips.html#ExternalStorage">Android Official Doc: Security Tips</a><br/>
    <a href="https://www.securecoding.cert.org/confluence/display/java/DRD00-J.+Do+not+store+sensitive+information+on+external+storage+%28SD+card%29+unless+encrypted+first">CERT: DRD00-J: Do not store sensitive information on external storage [...]</a><br/>
    <a href="http://developer.android.com/guide/topics/data/data-storage.html#filesExternal">Android Official Doc: Using the External Storage</a><br/>
    <a href="https://www.owasp.org/index.php/Mobile_Top_10_2014-M2">OWASP Mobile Top 10 2014-M2: Insecure Data Storage</a><br/>
    <a href="https://cwe.mitre.org/data/definitions/312.html">CWE-312: Cleartext Storage of Sensitive Information</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SERVLET_SESSION_ID">findsecbugs:SERVLET_SESSION_ID</a>
					</td>
					<td>
						<details>
							<p>
The method <a href="http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getRequestedSessionId()"><code>HttpServletRequest.getRequestedSessionId()</code></a>
typically returns the value of the cookie <code>JSESSIONID</code>. This value is normally only accessed by the session management logic and not normal developer code.
</p>
<p>
The value passed to the client is generally an alphanumeric value (e.g., <code>JSESSIONID=jp6q31lq2myn</code>). However, the value can be altered by the client. 
The following HTTP request illustrates the potential modification.
<pre>
GET /somePage HTTP/1.1
Host: yourwebsite.com
User-Agent: Mozilla/5.0
Cookie: JSESSIONID=Any value of the user&#39;s choice!!??'''&quot;&gt;
</pre>
</p>
<p>As such, the JSESSIONID should only be used to see if its value matches an existing session ID. If it does not, the user should be 
considered an unauthenticated user. In addition, the session ID value should never be logged. If it is, then the log file could contain 
valid active session IDs, allowing an insider to hijack any sessions whose IDs have been logged and are still active.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet">OWASP: Session Management Cheat Sheet</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>

</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:LDAP_ANONYMOUS">findsecbugs:LDAP_ANONYMOUS</a>
					</td>
					<td>
						<details>
							<p>
Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to abuse poorly configured LDAP environment. All LDAP queries executed against ctx will be performed without authentication and access control. An attacker may be able to manipulate one of these queries in an unexpected way to gain access to records that would otherwise be protected by the directory's access control mechanism.
</p>
<p>
    <b>Vulnerable Code:</b>
<pre>...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);
...</pre>
</p>
<p>
    <b>Solution:</b>
<br/>
Consider other modes of authentication to LDAP and ensure proper access control mechanism.

</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://docs.oracle.com/javase/tutorial/jndi/ldap/auth_mechs.html">Ldap Authentication Mechanisms</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SPRING_CSRF_PROTECTION_DISABLED">findsecbugs:SPRING_CSRF_PROTECTION_DISABLED</a>
					</td>
					<td>
						<details>
							<p>Disabling Spring Security's CSRF protection is unsafe for standard web applications.</p>
<p>A valid use case for disabling this protection would be a service exposing state-changing operations
that is guaranteed to be used only by non-browser clients.</p>
<p>
    <b>Insecure configuration:</b><br/>
<pre>@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable();
    }
}</pre>
</p>
<p>
<b>References</b><br/>
<a href="https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html#when-to-use-csrf-protection">Spring Security Official Documentation: When to use CSRF protection</a><br/>
<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">OWASP: Cross-Site Request Forgery</a><br/>
<a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet">OWASP: CSRF Prevention Cheat Sheet</a><br/>
<a href="https://cwe.mitre.org/data/definitions/352.html">CWE-352: Cross-Site Request Forgery (CSRF)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HTTP_PARAMETER_POLLUTION">findsecbugs:HTTP_PARAMETER_POLLUTION</a>
					</td>
					<td>
						<details>
							<p>
Concatenating unvalidated user input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach. HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks.<br/>
In the following example the programmer has not considered the possibility that an attacker could provide a lang such as en&user_id=1, which would enable him to change the user_id at will.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
<pre>String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.host.com");
get.setQueryString("lang=" + lang + "&user_id=" + user_id);
get.execute();</pre>
<p>
    <b>Solution:</b><br/>
Sanitize user input before using it in HTTP parameters.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://capec.mitre.org/data/definitions/460.html">CAPEC-460: HTTP Parameter Pollution (HPP)</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HTTPONLY_COOKIE">findsecbugs:HTTPONLY_COOKIE</a>
					</td>
					<td>
						<details>
							<p>
A new cookie is created without the <code>HttpOnly</code> flag set.
The <code>HttpOnly</code> flag is a directive to the browser to make sure that the cookie can not be red by
malicious script. When a user is the target of a "Cross-Site Scripting", the attacker would benefit greatly from getting
the session id for example.
</p>

<p>
<b>Code at risk:</b><br/>
<pre>
Cookie cookie = new Cookie("email",userName);
response.addCookie(cookie);
</pre>
</p>

<p>
<b>Solution (Specific configuration):</b><br/>
<pre>
Cookie cookie = new Cookie("email",userName);
cookie.setSecure(true);
cookie.setHttpOnly(true); //HttpOnly flag
</pre>
</p>

<p>
<b>Solution (Servlet 3.0 configuration):</b><br/>
<pre>
&lt;web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0"&gt;
[...]
&lt;session-config&gt;
 &lt;cookie-config&gt;
  &lt;http-only&gt;true&lt;/http-only&gt;
  &lt;secure&gt;true&lt;/secure&gt;
 &lt;/cookie-config&gt;
&lt;/session-config&gt;
&lt;/web-app&gt;
</pre>
</p>
<br/>
<p>
<b>Reference</b><br/>
<a href="http://blog.codinghorror.com/protecting-your-cookies-httponly/">Coding Horror blog: Protecting Your Cookies: HttpOnly</a><br/>
<a href="https://www.owasp.org/index.php/HttpOnly">OWASP: HttpOnly</a><br/>
<a href="https://www.rapid7.com/db/vulnerabilities/http-cookie-http-only-flag">Rapid7: Missing HttpOnly Flag From Cookie</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:FILE_UPLOAD_FILENAME">findsecbugs:FILE_UPLOAD_FILENAME</a>
					</td>
					<td>
						<details>
							<p>The filename provided by the FileUpload API can be tampered with by the client to reference unauthorized files.</p>
<p>For example:</p>
<ul>
<li><code>"../../../config/overide_file"</code></li>
<li><code>"shell.jsp\u0000expected.gif"</code></li>
</ul>
<p>Therefore, such values should not be passed directly to the filesystem API. If acceptable, the application should generate its 
own file names and use those. Otherwise, the provided filename should be properly validated to ensure it's properly structured, 
contains no unauthorized path characters (e.g., / \), and refers to an authorized file.</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://blogs.securiteam.com/index.php/archives/1268">Securiteam: File upload security recommendations</a><br/>
<a href="http://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a><br/>
<a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC-33: Path Traversal</a><br/>
<a href="https://www.owasp.org/index.php/Path_Traversal">OWASP: Path Traversal</a><br/>
<a href="http://capec.mitre.org/data/definitions/126.html">CAPEC-126: Path Traversal</a><br/>
<a href="http://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:PT_RELATIVE_PATH_TRAVERSAL">findbugs:PT_RELATIVE_PATH_TRAVERSAL</a>
					</td>
					<td>
						<details>
							<p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

See <a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of relative path traversal.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about relative path traversal, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:XSS_REQUEST_PARAMETER_TO_SEND_ERROR">findbugs:XSS_REQUEST_PARAMETER_TO_SEND_ERROR</a>
					</td>
					<td>
						<details>
							<p>This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows
for a reflected cross site scripting
vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of cross site scripting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting
vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:HRS_REQUEST_PARAMETER_TO_COOKIE">findbugs:HRS_REQUEST_PARAMETER_TO_COOKIE</a>
					</td>
					<td>
						<details>
							<p>This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting
vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:DMI_CONSTANT_DB_PASSWORD">findbugs:DMI_CONSTANT_DB_PASSWORD</a>
					</td>
					<td>
						<details>
							<p>This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can
    easily learn the password.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">findbugs:HRS_REQUEST_PARAMETER_TO_HTTP_HEADER</a>
					</td>
					<td>
						<details>
							<p>This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting
vulnerability. See <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of HTTP response splitting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:PT_ABSOLUTE_PATH_TRAVERSAL">findbugs:PT_ABSOLUTE_PATH_TRAVERSAL</a>
					</td>
					<td>
						<details>
							<p>The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory,
but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.

See <a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of absolute path traversal.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more
vulnerabilities that SpotBugs doesn't report. If you are concerned about absolute path traversal, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">findbugs:SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE</a>
					</td>
					<td>
						<details>
							<p>The method invokes the execute or addBatch method on an SQL statement with a String that seems
to be dynamically generated. Consider using
a prepared statement instead. It is more efficient and less vulnerable to
SQL injection attacks.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">findbugs:XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER</a>
					</td>
					<td>
						<details>
							<p>This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting
vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of cross site scripting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting
vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:DMI_EMPTY_DB_PASSWORD">findbugs:DMI_EMPTY_DB_PASSWORD</a>
					</td>
					<td>
						<details>
							<p>This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findbugs:SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">findbugs:SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING</a>
					</td>
					<td>
						<details>
							<p>The code creates an SQL prepared statement from a nonconstant String.
If unchecked, tainted data from a user is used in building this String, SQL injection could
be used to make the prepared statement do something unexpected and undesirable.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:JSP_JSTL_OUT">findsecbugs-jsp:JSP_JSTL_OUT</a>
					</td>
					<td>
						<details>
							<p>A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references)
</p>
<p>
    <b>Vulnerable Code:</b>
    <pre>&lt;%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %&gt;

&lt;c:out value="${param.test_param}" escapeXml="false"/&gt;</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>&lt;%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %&gt;

&lt;c:out value="${param.test_param}"/&gt;</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">WASC-8: Cross Site Scripting</a><br/>
<a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">OWASP: XSS Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)</a><br/>
<a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a><br/>
<a href="http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/c/out.html">JSTL Javadoc: Out tag</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:XSS_JSP_PRINT">findsecbugs-jsp:XSS_JSP_PRINT</a>
					</td>
					<td>
						<details>
							<p>A potential XSS was found. It could be used to execute unwanted JavaScript in a client's browser. (See references)
</p>
<p>
    <b>Vulnerable Code:</b>
    <pre><%
String taintedInput = (String) request.getAttribute("input");
%>
[...]
&lt;%= taintedInput %&gt;</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>
&lt;%
String taintedInput = (String) request.getAttribute("input");
%&gt;
[...]
&lt;%= Encode.forHtml(taintedInput) %&gt;
    </pre>
</p>
<p>
The best defense against XSS is context sensitive output encoding like the example above. There are typically 4 contexts to consider: 
HTML, JavaScript, CSS (styles), and URLs. Please follow the XSS protection rules defined in the OWASP XSS Prevention Cheat Sheet,
which explains these defenses in significant detail.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting">WASC-8: Cross Site Scripting</a><br/>
<a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">OWASP: XSS Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">OWASP: Top 10 2013-A3: Cross-Site Scripting (XSS)</a><br/>
<a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a><br/>
<a href="https://code.google.com/p/owasp-java-encoder/">OWASP Java Encoder</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:JSP_XSLT">findsecbugs-jsp:JSP_XSLT</a>
					</td>
					<td>
						<details>
							<p>
    "XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents".<sup>[1]</sup><br/>
    It is possible to attach malicious behavior to those stylesheets. Therefore, if an attacker can control the content or the source of the
    stylesheet, he might be able to trigger remote code execution.<sup>[2]</sup>
</p>
<p>
<b>Code at risk:</b><br/>
<pre>
&#x3C;x:transform xml=&#x22;${xmlData}&#x22; xslt=&#x22;${xsltControlledByUser}&#x22; /&#x3E;
</pre>
</p>
<p>
<b>Solution:</b><br/>
<p>
The solution would be to make sure the stylesheet is loaded from a safe sources and make sure that vulnerabilities such as
Path traversal <sup>[3][4]</sup> are not possible.
</p>
<p>
<b>References</b><br/>
[1] <a href="https://en.wikipedia.org/wiki/XSLT">Wikipedia: XSLT (Extensible Stylesheet Language Transformations)</a><br/>
<a href="https://prezi.com/y_fuybfudgnd/offensive-xslt/">Offensive XSLT</a> by Nicolas Gregoire<br/>
[2] <a href="http://www.agarri.fr/kom/archives/2012/07/02/from_xslt_code_execution_to_meterpreter_shells/index.html">From XSLT code execution to Meterpreter shells</a> by Nicolas Gregoire<br/>
<a href="http://xhe.myxwiki.org/xwiki/bin/view/Main/">XSLT Hacking Encyclopedia</a> by Nicolas Gregoire<br/>
<a href="http://www.acunetix.com/blog/articles/the-hidden-dangers-of-xsltprocessor-remote-xsl-injection/">Acunetix.com : The hidden dangers of XSLTProcessor - Remote XSL injection</a><br/>
<a href="https://www.w3.org/TR/xslt">w3.org XSL Transformations (XSLT) Version 1.0</a> : w3c specification<br/>
[3] <a href="http://projects.webappsec.org/w/page/13246952/Path%20Traversal">WASC: Path Traversal</a><br/>
[4] <a href="https://www.owasp.org/index.php/Path_Traversal">OWASP: Path Traversal</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:XSS_REQUEST_PARAMETER_TO_JSP_WRITER">findsecbugs-jsp:XSS_REQUEST_PARAMETER_TO_JSP_WRITER</a>
					</td>
					<td>
						<details>
							<p>This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting
vulnerability. See <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a>
for more information.</p>
<p>SpotBugs looks only for the most blatant, obvious cases of cross site scripting.
If SpotBugs found <em>any</em>, you <em>almost certainly</em> have more cross site scripting
vulnerabilities that SpotBugs doesn't report. If you are concerned about cross site scripting, you should seriously
consider using a commercial static analysis or pen-testing tool.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:JSP_INCLUDE">findsecbugs-jsp:JSP_INCLUDE</a>
					</td>
					<td>
						<details>
							<p>The inclusion of JSP file allow the entry of dynamic value. It may allow an attacker to control the JSP page included.
If this is the case, an attacker will try to include a file on disk that he controls. By including arbitrary files, the
attacker gets the ability to execute any code.
</p>
<p>
    <b>Vulnerable Code:</b>
    <pre>&lt;jsp:include page="${param.secret_param}" /&gt;</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>&lt;c:if test="${param.secret_param == 'page1'}"&gt;
    &lt;jsp:include page="page1.jsp" /&gt;
&lt;/c:if&gt;</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://resources.infosecinstitute.com/file-inclusion-attacks/">InfosecInstitute: File Inclusion Attacks</a><br/>
<a href="http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion">WASC-05: Remote File Inclusion</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs-jsp:JSP_SPRING_EVAL">findsecbugs-jsp:JSP_SPRING_EVAL</a>
					</td>
					<td>
						<details>
							<p>A Spring expression is built with a dynamic value. The source of the value(s) should be verified to avoid that unfiltered values fall into this risky code evaluation.
</p>
<p>
    <b>Vulnerable Code:</b>
    <pre>&lt;%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %&gt;

&lt;spring:eval expression="${param.lang}" var="lang" /&gt;</pre>
    <br>
    <pre>&lt;%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %&gt;

&lt;spring:eval expression="'${param.lang}'=='fr'" var="languageIsFrench" /&gt;</pre>
</p>
<p>
    <b>Solution:</b>
    <pre>&lt;c:set var="lang" value="${param.lang}"/&gt;</pre>
    <br/>
    <pre>&lt;c:set var="languageIsFrench" value="${param.lang == 'fr'}"/&gt;</pre>
</p>
<br/>
<p>
<b>References</b><br/>
    <a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a><br/>
    <a href="http://cwe.mitre.org/data/definitions/95.html">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2068">php:S2068</a>
					</td>
					<td>
						<details>
							<p>Because it is easy to extract strings from a compiled application, credentials should never be hard-coded. Do so, and they're almost guaranteed to
end up in the hands of an attacker. This is particularly true for applications that are distributed.</p>
<p>Credentials should be stored outside of the code in a strongly-protected encrypted configuration file or database.</p>
<h2>Noncompliant Code Example</h2>
<pre>
$uname = "steve";
$password = "blue";
connect($uname, $password);
</pre>
<h2>Compliant Solution</h2>
<pre>
$uname = getEncryptedUser();
$password = getEncryptedPass();
connect($uname, $password);
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
  <li> <a href="http://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Porous Defenses </li>
  <li> <a href="https://www.securecoding.cert.org/confluence/x/qQCHAQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">OWASP Top Ten 2013 Category A2</a> -
  Broken Authentication and Session Management </li>
  <li> Derived from FindSecBugs rule <a href="http://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S2964">php:S2964</a>
					</td>
					<td>
						<details>
							<p><code>sleep</code> is sometimes used in a mistaken attempt to prevent Denial of Service (DoS) attacks by throttling response rate. But because it
ties up a thread, each request takes longer to serve that it otherwise would, making the application <em>more</em> vulnerable to DoS attacks, rather
than less.</p>
<h2>Noncompliant Code Example</h2>
<pre>
if (is_bad_ip($requester)) {
  sleep(5);  // Noncompliant
}
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S1523">php:S1523</a>
					</td>
					<td>
						<details>
							<p>The <code>eval</code> function is a way to run arbitrary code at run-time. </p>
<p>According to the PHP documentation</p>
<blockquote>
  <p>The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have
  carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it
  without properly validating it beforehand.</p>
</blockquote>
<h2>Noncompliant Code Example</h2>
<pre>
eval($code_to_be_dynamically_executed)
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/95.html">MITRE CWE-95</a> - CWE-95: Improper Neutralization of Directives in Dynamically
  Evaluated Code ('Eval Injection') </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)">OWASP Top Ten 2013 Category A3</a> - Cross-Site Scripting
  (XSS) </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3336">php:S3336</a>
					</td>
					<td>
						<details>
							<p>PHP's <code>session.use_trans_sid</code> automatically appends the user's session id to urls when cookies are disabled. On the face of it, this
seems like a nice way to let uncookie-able users use your site anyway. In reality, it makes those users vulnerable to having their sessions hijacked
by anyone who might:</p>
<ul>
  <li> see the URL over the user's shoulder </li>
  <li> be sent the URL by the user </li>
  <li> retrieve the URL from browser history </li>
  <li> ... </li>
</ul>
<p>For that reason, it's better to practice a little "tough love" with your users and force them to turn on cookies.</p>
<p>Since <code>session.use_trans_sid</code> is off by default, this rule raises an issue when it is explicitly enabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
session.use_trans_sid=1  ; Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration">OWASP Top Ten 2013 Category A5</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3337">php:S3337</a>
					</td>
					<td>
						<details>
							<p><code>enable_dl</code> is on by default and allows <code>open_basedir</code> restrictions, which limit the files a script can access, to be
ignored. For that reason, it's a dangerous option and should be explicitly turned off.</p>
<p>This rule raises an issue when <code>enable_dl</code> is not explicitly set to 0 in <em>php.ini</em>.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
enable_dl=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
enable_dl=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/23.html">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/36.html">MITRE, CWE-36</a> - Absolute Path Traversal </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3334">php:S3334</a>
					</td>
					<td>
						<details>
							<p><code>allow_url_fopen</code> and <code>allow_url_include</code> allow code to be read into a script from URL's. The ability to suck in executable
code from outside your site, coupled with imperfect input cleansing could lay your site bare to attackers. Even if your input filtering is perfect
today, are you prepared to bet your site that it will always be perfect in the future?</p>
<p>This rule raises an issue when either property is explicitly enabled in <em>php.ini</em> and when <code>allow_url_fopen</code>, which defaults to
enabled, is not explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini  Noncompliant; allow_url_fopen not explicitly disabled
allow_url_include=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
allow_url_fopen=0
allow_url_include=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/829.html">MITRE, CWE-829</a> - Inclusion of Functionality from Untrusted Control Sphere </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP Top Ten 2013 Category A1</a> - Injection </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Risky Resource Management </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3335">php:S3335</a>
					</td>
					<td>
						<details>
							<p>The <code>cgi.force_redirect</code> <em>php.ini</em> configuration is on by default, and it prevents unauthenticated access to scripts when PHP is
running as a CGI. Unfortunately, it must be disabled on IIS, OmniHTTPD and Xitami, but in all other cases it should be on.</p>
<p>This rule raises an issue when when <code>cgi.force_redirect</code> is explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
cgi.force_redirect=0  ; Noncompliant
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/305">MITRE, CWE-305</a> - Authentication Bypass by Primary Weakness </li>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration">OWASP Top Ten 2013 Category A5</a> - Security
  Misconfiguration </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3332">php:S3332</a>
					</td>
					<td>
						<details>
							<p>Cookies without fixed lifetimes or expiration dates are known as non-persistent, or "session" cookies, meaning they last only as long as the
browser session, and poof away when the browser closes. Cookies with expiration dates, "persistent" cookies, are stored/persisted until those
dates.</p>
<p>Non-persistent cookies should be used for the management of logged-in sessions on web sites. To make a cookie non-persistent, simply omit the
<code>expires</code> attribute.</p>
<p>This rule raises an issue when <code>expires</code> is set for a session cookie, either programmatically or via configuration, such as
<code>session.cookie_lifetime</code>.</p>
<h2>See</h2>
<ul>
  <li> <a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)">OWASP Top Ten 2013 Category A3</a> - Cross-Site Scripting
  (XSS) </li>
  <li> <a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Expire_and_Max-Age_Attributes">OWASP, Session Management Cheat
  Sheet</a> - Expire and Max-Age Attributes </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3333">php:S3333</a>
					</td>
					<td>
						<details>
							<p>The <code>open_basedir</code> configuration in <em>php.ini</em> limits the files the script can access using, for example, <code>include</code> and
<code>fopen()</code>. Leave it out, and there is no default limit, meaning that any file can be accessed. Include it, and PHP will refuse to access
files outside the allowed path.</p>
<p><code>open_basedir</code> should be configured with a directory, which will then be accessible recursively. However, the use of <code>.</code>
(current directory) as an <code>open_basedir</code> value should be avoided since it's resolved dynamically during script execution, so a
<code>chdir('/')</code> command could lay the whole server open to the script.</p>
<p>This is not a fool-proof configuration; it can be reset or overridden at the script level. But its use should be seen as a minimum due diligence
step. This rule raises an issue when <code>open_basedir</code> is not present in <em>php.ini</em>, and when <code>open_basedir</code> contains root,
or the current directory (<code>.</code>) symbol.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini try 1
; open_basedir="${USER}/scripts/data"  Noncompliant; commented out

; php.ini try 2
open_basedir="/:${USER}/scripts/data"  ; Noncompliant; root directory in the list
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini try 1
open_basedir="${USER}/scripts/data"
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/23.html">MITRE, CWE-23</a> - Relative Path Traversal </li>
  <li> <a href="https://cwe.mitre.org/data/definitions/36.html">MITRE, CWE-36</a> - Absolute Path Traversal </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=php:S3338">php:S3338</a>
					</td>
					<td>
						<details>
							<p><code>file_uploads</code> is an on-by-default PHP configuration that allows files to be uploaded to your site. Since accepting <del>candy</del>
files from strangers is inherently dangerous, this feature should be disabled unless it is absolutely necessary for your site.</p>
<p>This rule raises an issue when <code>file_uploads</code> is not explicitly disabled.</p>
<h2>Noncompliant Code Example</h2>
<pre>
; php.ini
file_uploads=1  ; Noncompliant
</pre>
<h2>Compliant Solution</h2>
<pre>
; php.ini
file_uploads=0
</pre>
<h2>See</h2>
<ul>
  <li> <a href="https://cwe.mitre.org/data/definitions/434.html">MITRE, CWE-434</a> - Unrestricted Upload of File with Dangerous Type </li>
  <li> <a href="http://www.sans.org/top25-software-errors/">SANS Top 25</a> - Insecure Interaction Between Components </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:HARD_CODE_PASSWORD">findsecbugs:HARD_CODE_PASSWORD</a>
					</td>
					<td>
						<details>
							<p>
Passwords should not be kept in the source code. The source code can be widely shared in an enterprise environment, and is
certainly shared in open source. To be managed safely, passwords and secret keys should be stored in separate configuration files or keystores.
(Hard coded keys are reported separately by <i>Hard Coded Key</i> pattern)
</p>
<p>
<p><b>Vulnerable Code:</b><br/>

<pre>private String SECRET_PASSWORD = "letMeIn!";

Properties props = new Properties();
props.put(Context.SECURITY_CREDENTIALS, "p@ssw0rd");</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://cwe.mitre.org/data/definitions/259.html">CWE-259: Use of Hard-coded Password</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XPATH_INJECTION">findsecbugs:XPATH_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
XPath injection risks are similar to SQL injection. If the XPath query contains untrusted user input, the complete datasource
could be exposed. This could allow an attacker to access unauthorized data or maliciously modify the target XML.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-39: XPath Injection</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/643.html">CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')</a><br/>
<a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=61407250">CERT: IDS09-J. Prevent XPath Injection (archive)</a><br/>
<a href="http://media.blackhat.com/bh-eu-12/Siddharth/bh-eu-12-Siddharth-Xpath-WP.pdf">Black Hat Europe 2012: Hacking XPath 2.0</a><br/>
<a href="http://www.balisage.net/Proceedings/vol7/html/Vlist02/BalisageVol7-Vlist02.html">Balisage: XQuery Injection</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SCRIPT_ENGINE_INJECTION">findsecbugs:SCRIPT_ENGINE_INJECTION</a>
					</td>
					<td>
						<details>
							<p>
    Dymanic code is being evaluate. A careful analysis of the code construction should be made. Malicious code execution
    could lead to data leakage or operating system compromised.
</p>
<p>
    If the evaluation of user code is intended, a proper sandboxing should be applied (see references).
</p>

<p><b>Code at risk:</b></p>
<p>
<pre>
public void runCustomTrigger(String script) {
    ScriptEngineManager factory = new ScriptEngineManager();
    ScriptEngine engine = factory.getEngineByName("JavaScript");

    engine.eval(script); //Bad things can happen here.
}</pre>
</p>

<p><b>Solution:</b></p>
<p>
Safe evaluation of Javascript code using "Cloudbees Rhino Sandbox" library.<br/>
<pre>
public void runCustomTrigger(String script) {
    SandboxContextFactory contextFactory = new SandboxContextFactory();
    Context context = contextFactory.makeContext();
    contextFactory.enterContext(context);
    try {
        ScriptableObject prototype = context.initStandardObjects();
        prototype.setParentScope(null);
        Scriptable scope = context.newObject(prototype);
        scope.setPrototype(prototype);

        context.evaluateString(scope,script, null, -1, null);
    } finally {
        context.exit();
    }
}</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://github.com/cloudbees/rhino-sandbox">Cloudbees Rhino Sandbox</a>: Utility to create sandbox with Rhino (block access to all classes)<br/>
<a href="http://codeutopia.net/blog/2009/01/02/sandboxing-rhino-in-java/">CodeUtopia.net: Sandboxing Rhino in Java</a><br/>
<a href="http://blog.h3xstream.com/2014/11/remote-code-execution-by-design.html">Remote Code Execution .. by design</a>: Example of malicious payload. The samples given could be used to test sandboxing rules.<br/>
<a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a><br/>
<a href="https://cwe.mitre.org/data/definitions/95.html">CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:SQL_INJECTION_JDO">findsecbugs:SQL_INJECTION_JDO</a>
					</td>
					<td>
						<details>
							<p>
The input values included in SQL queries need to be passed in safely.
Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection.
</p>
<p>
    <b>Vulnerable Code:</b><br/>
    <pre>
PersistenceManager pm = getPM();

Query q = pm.newQuery("select * from Users where name = " + input);
q.execute();</pre>
</p>
<p>
    <b>Solution:</b><br/>
    <pre>
PersistenceManager pm = getPM();

Query q = pm.newQuery("select * from Users where name = nameParam");
q.declareParameters("String nameParam");
q.execute(input);</pre>
</p>
<br/>
<p>
<b>References (JDO)</b><br/>
<a href="https://db.apache.org/jdo/object_retrieval.html">JDO: Object Retrieval</a><br/>
<b>References (SQL injection)</b><br/>
<a href="http://projects.webappsec.org/w/page/13246963/SQL%20Injection">WASC-19: SQL Injection</a><br/>
<a href="http://capec.mitre.org/data/definitions/66.html">CAPEC-66: SQL Injection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/89.html">CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">OWASP: Top 10 2013-A1-Injection</a><br/>
<a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">OWASP: SQL Injection Prevention Cheat Sheet</a><br/>
<a href="https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet">OWASP: Query Parameterization Cheat Sheet</a><br/>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:STATIC_IV">findsecbugs:STATIC_IV</a>
					</td>
					<td>
						<details>
							<p>
    Initialization vector must be regenerated for each message to be encrypted.
</p>
<p><b>Vulnerable Code:</b></p>
<p>
<pre>
private static byte[] IV = new byte[16] {(byte)0,(byte)1,(byte)2,[...]};

public void encrypt(String message) throws Exception {

    IvParameterSpec ivSpec = new IvParameterSpec(IV);
[...]
</pre>
<p><b>Solution:</b></p>
<p>
<pre>
public void encrypt(String message) throws Exception {

    byte[] iv = new byte[16];
    new SecureRandom().nextBytes(iv);

    IvParameterSpec ivSpec = new IvParameterSpec(iv);
[...]
</pre>
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://en.wikipedia.org/wiki/Initialization_vector">Wikipedia: Initialization vector</a><br/>
<a href="http://cwe.mitre.org/data/definitions/329.html">CWE-329: Not Using a Random IV with CBC Mode</a><br/>
<a href="https://defuse.ca/cbcmodeiv.htm">Encryption - CBC Mode IV: Secret or Not?</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:XML_DECODER">findsecbugs:XML_DECODER</a>
					</td>
					<td>
						<details>
							<p>
    XMLDecoder should not be used to parse untrusted data. Deserializing user input can lead to arbitrary code execution.
    This is possible because XMLDecoder supports arbitrary method invocation. This capability is intended to call setter methods,
    but in practice, any method can be called.
</p>
<p>
    <b>Malicious XML example:</b>
</p>
<pre>
&lt;?xml version="1.0" encoding="UTF-8" ?&gt;
&lt;java version="1.4.0" class="java.beans.XMLDecoder"&gt;
  &lt;object class="java.io.PrintWriter"&gt;
    &lt;string>/tmp/Hacked.txt&lt;/string&gt;
    &lt;void method="println"&gt;
      &lt;string>Hello World!&lt;/string&gt;
    &lt;/void&gt;
    &lt;void method="close"/&gt;
  &lt;/object&gt;
&lt;/java&gt;
</pre>
<p>
The XML code above will cause the creation of a file with the content "Hello World!".
</p>
<p>
    <b>Vulnerable Code:</b></br/>
    <pre>XMLDecoder d = new XMLDecoder(in);
try {
    Object result = d.readObject();
}
[...]</pre>
</p>
<p>
<b>Solution:</b></br/>
The solution is to avoid using XMLDecoder to parse content from an untrusted source.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html">Dinis Cruz Blog: Using XMLDecoder to execute server-side Java Code on an Restlet application</a><br/>
<a href="https://securityblog.redhat.com/2014/01/23/java-deserialization-flaws-part-2-xml-deserialization/">RedHat blog : Java deserialization flaws: Part 2, XML deserialization</a><br/>
<a href="http://cwe.mitre.org/data/definitions/20.html">CWE-20: Improper Input Validation</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=findsecbugs:UNENCRYPTED_SOCKET">findsecbugs:UNENCRYPTED_SOCKET</a>
					</td>
					<td>
						<details>
							<p>
The communication channel used is not encrypted. The traffic could be read by an attacker intercepting the network traffic.
</p>
<p>
<b>Vulnerable Code:</b><br/>
Plain socket (Cleartext communication):
<pre>Socket soc = new Socket("www.google.com",80);</pre>
</p>
<p>
<b>Solution:</b><br/>
SSL Socket (Secure communication):
<pre>Socket soc = SSLSocketFactory.getDefault().createSocket("www.google.com", 443);</pre>
</p>
<p>Beyond using an SSL socket, you need to make sure your use of SSLSocketFactory does all the appropriate certificate validation checks to
make sure you are not subject to man-in-the-middle attacks. Please read the OWASP Transport Layer Protection Cheat Sheet for details on how
to do this correctly.
</p>
<br/>
<p>
<b>References</b><br/>
<a href="https://www.owasp.org/index.php/Top_10_2010-A9">OWASP: Top 10 2010-A9-Insufficient Transport Layer Protection</a><br/>
<a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">OWASP: Top 10 2013-A6-Sensitive Data Exposure</a><br/>
<a href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">OWASP: Transport Layer Protection Cheat Sheet</a><br/>
<a href="http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection">WASC-04: Insufficient Transport Layer Protection</a><br/>
<a href="http://cwe.mitre.org/data/definitions/319.html">CWE-319: Cleartext Transmission of Sensitive Information</a>
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=pmd:MethodReturnsInternalArray">pmd:MethodReturnsInternalArray</a>
					</td>
					<td>
						<details>
							Exposing internal arrays directly allows the user to modify some code that could be critical. It is safer to return a copy of the array.

<p>
  This rule is deprecated, use <a href='/coding_rules#rule_key=squid%3AS2384'>S2384</a> instead.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=pmd:ArrayIsStoredDirectly">pmd:ArrayIsStoredDirectly</a>
					</td>
					<td>
						<details>
							Constructors and methods receiving arrays should clone objects and store the copy. This prevents that future changes from the user affect the internal functionality.

<p>
  This rule is deprecated, use <a href='/coding_rules#rule_key=squid%3AS2384'>S2384</a> instead.
</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:S3394">cdk-cobol-rules:S3394</a>
					</td>
					<td>
						<details>
							<p>The <code>ACCEPT</code> keyword does no editing or error checking of the data it stores, therefore its use can be dangerous. For this reason,
<code>ACCEPT</code> should be avoided. </p>
<h2>Noncompliant Code Example</h2>
<pre>
 01 USER-INPUT PIC X(4).

  GET-USER-INPUT.
       MOVE 'N' TO WS-NUMERIC.
       PERFORM UNTIL WS-NUMERIC = 'Y'
           DISPLAY 'ENTER YOUR 4 DIGIT RECORD NUMBER: ' NO ADVANCING
           ACCEPT USER-RECORD *&gt; Noncompliant
</pre>
<h2>Exceptions</h2>
<p>This rule ignores uses of <code>ACCEPT FROM</code> with date/time-related inputs.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:SQL.SelectWithNoWhereClauseCheck">cdk-cobol-rules:SQL.SelectWithNoWhereClauseCheck</a>
					</td>
					<td>
						<details>
							<p>Although the <code>WHERE</code> condition is optional in a <code>SELECT</code> statement, for performance and security reasons, a
<code>WHERE</code> clause should always be specified to prevent reading the whole table.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SELECT * FROM db_persons INTO us_persons
</pre>
<h2>Compliant Solution</h2>
<pre>
SELECT * FROM db_persons INTO us_persons WHERE country IS 'US'
</pre>
<h2>Exceptions</h2>
<p>Not having a WHERE clause is acceptable in read-only cursors as results are generally sorted and it is possible to stop processing in the
middle.</p>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:SQL.DynamicSqlCheck">cdk-cobol-rules:SQL.DynamicSqlCheck</a>
					</td>
					<td>
						<details>
							<p>It is a bad practice to use Dynamic SQL. It differs from static embedded SQL in that part or all of the actual SQL commands may be stored in a host
variable that is built on the fly during execution of the program. In the extreme case, the SQL commands are generated in their entirety by the
application program at run time. While dynamic SQL is more flexible than static embedded SQL, it does require additional overhead and is much more
difficult to understand and to maintain.</p>
<p>Moreover, dynamic SQL may expose the application to SQL injection vulnerabilities.</p>
<p>This rule raises an issue when <code>PREPARE</code> or <code>EXECUTE IMMEDIATE</code> is used.</p>
<h2>Noncompliant Code Example</h2>
<pre>
EXEC SQL PREPARE SEL INTO :SQLDA FROM :STMTBUF END-EXEC.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:S1686">cdk-cobol-rules:S1686</a>
					</td>
					<td>
						<details>
							<p>Defining a subprogram to be called at runtime is possible but ill-advised. This extremely powerful feature can quite easily be misused, and even
when used correctly, it highly increases the overall complexity of the program, and makes it impossible before runtime to know exactly what will be
executed. Therefore defining the subprogram to be called at runtime is a feature that should be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
MOVE SOMETHING TO MY_SUBPROG.
...
CALL MY_SUBPROG.
</pre>
<h2>Compliant Solution</h2>
<pre>
01 MY_SUBPROG PIC X(10) VALUE "SUB123".
....
CALL MY_SUBPROG.
</pre>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:S1685">cdk-cobol-rules:S1685</a>
					</td>
					<td>
						<details>
							<p>Debug statements (ones with 'D' or 'd' in the indicator area) should not be executed in production, but the <code>WITH DEBUGGING MODE</code> clause
activates all debug lines, which could expose sensitive information to attackers. Therefore the <code>WITH DEBUGGING MODE</code> clause should be
removed.</p>
<h2>Noncompliant Code Example</h2>
<pre>
SOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE.
</pre>
<h2>Compliant Solution</h2>
<pre>
SOURCE-COMPUTER. IBM-370.
</pre>
<h2>See</h2>
<ul>
  <li> <a href="http://cwe.mitre.org/data/definitions/489.html">MITRE, CWE-489</a> - Leftover Debug Code </li>
</ul>
						</details>
					</td>
				</tr>
				
				<tr>
					<td><a
							href="https://next.sonarqube.com/sonarqube/coding_rules#rule_key=cdk-cobol-rules:COBOL.DisplayStatementUsageCheck">cdk-cobol-rules:COBOL.DisplayStatementUsageCheck</a>
					</td>
					<td>
						<details>
							<p>The <code>DISPLAY</code> statement outputs data to standard out or some other destination and could reveal sensitive information. Therefore, it
should be avoided.</p>
<h2>Noncompliant Code Example</h2>
<pre>
DISPLAY "hello world"  *&gt; Noncompliant
</pre>
						</details>
					</td>
				</tr>
				
			</tbody>
		</table>
	</div>

	

	<script>
		var canvas = document.getElementById("vulnerabilitiesPieChart");
		var ctx = canvas.getContext("2d");

		var data = [ 
			19 ,
			0 ,
			5 ,
			13
		];
		var total = data.reduce(function (sum, n) {
			return sum + n;
		})
		var colors = ['#2c3e50', '#d43223', '#f39c12', '#319ddb'];

		for (var i = 0, lastend = 0; i < data.length; i++) {
			ctx.fillStyle = colors[i];
			ctx.beginPath();
			ctx.moveTo(canvas.width / 2, canvas.height / 2);
			ctx.arc(canvas.width / 2, canvas.height / 2, canvas.height / 2, lastend, lastend + (Math.PI * 2 * (data[i] /
				total)), false);
			ctx.lineTo(canvas.width / 2, canvas.height / 2);
			ctx.fill();
			lastend += Math.PI * 2 * (data[i] / total);
		}
	</script>

	
</body>

</html>
